Skip to main content

Service Oriented Architects

Posted by johnreynolds on February 7, 2006 at 5:48 PM PST

In his XML Annoynaces blog, Micah Dubinko offers his perspective on software architecture and architects:

"It goes without saying that a major development project should have a solid architect at the core. A good architect needs to be able to separate personal preferences and prejudices from legitimate good design points--in other words, get the focus right. A concrete measure of an architect is whether outside groups--even ones that wouldn't normally be directly involved--are able to understand and accept the architecture. There will be times where it's just not possible to please everyone to the level of consensus, but still it provides a measuring rod against which to evaluate a design (or a designer)."

Micah is right; the true measure of an architect is whether or not they "get the focus right".

If you work with an IT group, you (like me) are probably involved in some sort of Service Oriented Architecture discovery or implementation project; Gartner predicts that SOA will provide the basis for 80 percent of development projects by 2008.

Given this huge trend towards SOA, we really need Service Oriented Architects who can "get the focus right".

Reuse is an often mentioned benefit of SOA, but I believe that SOA's key benefit is the closer mapping between business processes and the implementation. SOA meshes perfectly with Process Driven Design.

Many Object Oriented (Jave and C++) projects have great technical architectures, but the business process implementation ends up scattered across many modules and hidden in the code. When a business process changes (and they often do) it is quite often difficult (or at least tedious) to implement and deploy the process oriented changes: Not exactly what business wants.

I don't know why this happens, but I suspect a subtle impedance mis-match between form (architectural style) and function (what the program is meant to do).
Perhaps Object Oriented architects tend to focus on UML Class Diagrams more than on UML Activity Diagrams?

Unlike Object-Oriented design, SOA is tailored to solve problems in a specific domain. As Miko Matsumura puts it:

"there are nearly an infinite number of software programming problems—game programming, graphics, engineering, mathematics, statistical modeling, you name it. The SOA that is getting people all hot and bothered isn't particularly interesting as a solution for all of these other problems. SOA is for business."

Service Oriented Architects need to focus on business processes and on business services. The SOA architect has to understand where a business process is likely to change, and where it probably won't. They need to understand factors that impact multiple process steps, and those that are specific to a single step. Without this level of business knowledge SOA architects will not be able to design services with the proper granularity, and they won't be able to design the proper data interchange model.

If this begins to sound a lot more like a Business Architect than a Technical Architect... I've made my point.


Useful links:
Related Topics >>