I went to CA this past weekend to help my friend Luke Hohmann celebrate a birthday. Besides playing with his beautiful children, we spent quite a few hours talking about industry trends, his work at developing a methodical approach to wholistic product management, and my current efforts applying SOA.
In January, Luke was Guest Editor of the Cutter IT Journal entitled "The Business of Software Architecture". His parting gift to me was a paper copy to read on the plane. In it, Jim Coplien has an article about the need for a better match between business requirements and analysis methods.
Coplien acurately states that while requirements modeling in use cases does well at describing process flow, popular OOA&D methods focus on Class as the only first-class entity in an attempt to force everything into an object-oriented paradigm. However, in the world of Web services, data types become merely descriptive while services themselves are the main focus. In traditional OOA&D, such abstractions as Service Managers are anthropomorphized design creations to put facades on subsystems or other cohesive groups of objects.
However, another techniqued called the Object Oriented Role Analysis Method takes a multi-pass approach to analysis where roles and responsibilities are considered first, and then synthesized into objects according to some heuristics for cohesion and coupling. Before this point of synthesis, you have roles and types. Jim points out that roles map to the increasingly important Interface abstraction in modern languages. They also map well to Services in an SOA.
Many years ago I saw OORAM in action. I was interviewing a candidate from Brussles who was a huge proponent of the method. I gave him some difficult design problems that using a class-driven approach required the application of several design patterns to avoid a brittle, hard to extend system. This candidate adeptly applied OORAM, very quickly I might add, to naturally arrive at the optimal solution. Ironically, we didn't hire him because the technical lead of the interview process didn't like the process and said he was "lucky". Since then I've occasionally pulled OORAM out of my back pocket to address tricky situations. It has always served me well at providing another view point and clarifying the allocation of responsibilities.
Fast forward to the present.... I find myself dealing with Services and Types, and the challenges of mentoring OO developers through the application of heuristics for service granularity and the separation of concerns. Thanks to Jim's artical raising its significance again, I intend to start formally applying OORAM to service definition problems. I'll let you know how it goes.
Comments