Software Architects and Architecture (SOA 1)
Sunday, September 16, 2007 at 07:19PM
Toby Considine in Background, System Architecture

I often use the word Architecture when talking about systems. I often get blank looks, or nods that are so quick that conceal a lack of understanding. This leads me to answer the question, so what do I think a systems architect does? Is an architect the senior programmer? What does an architect produce? What should programmers know about architecture?

I don't think architects are just senior developers. It's a different skill. Architects work primarily in models, patterns and process, not code. There are different process patterns that an architect can work with.

One prominent pattern is the Service. A service is a fundamental business function, stripped of process. I say stripped of process because procedures are often mere accretions of tradition. One can’t look to the procedures to see if the service is proper, or what the correct metrics should be.

Think of it this way. I am a regular customer of yours. Your shipping department provides a shipping and logistics service. Your shipping staff may be friendly, and polite. If you find out that I know every one of these friendly guys by first name, you should be concerned about the service you provide. Why do I need to call them so much? Do my shipments never arrive on time? Do I frequently need to arrange for returns of defective merchandise?

I won’t be happy if you automate this system without addressing the underlying issues. If you set your programmers to enshrine your current process in code, the service will still b bad, and you will lose the benefit of your friendly staff. If you work on improving the current processes, but select the wrong metrics, you will waste a lot of resources. All that time you spend training the process of training your shipping staff in customer service will be wasted because I still need to talk to them regularly.

Service Oriented Architecture is the discipline of finding the proper surface on each function, that is the proper interaction between that function and all others, internal or external. In a business it must be a joint process with full participation between IT and business management.

If for some reason, only one side can participate, the business manager participation is the more important of the two. A business that has defined its internal functions as services, a Service Oriented Enterprise, will always be healthier than a business that defines its internal functions as procedures, the Procedure Oriented Enterprise. As someone once said, the problem government, universities, and very large corporations is that they attract people for whom means easily become ends. It also has been said that implementing a business function as a service is trivial in Service Oriented Enterprise.

Companies that understand this quite well still get it wrong sometimes. Dell built its business using a virtual inventory and supply chain based upon solid service oriented principles. Its customers trusted it and the Dell experience. It outsourced its tech support function badly, outsourcing the process rather than the service. Its partners success metrics were process oriented rather than service oriented. Dell took a beating in customer perception.

Next: Applying Service Orientation to the world of Engineered Systems.

Article originally appeared on New Daedalus (http://www.newdaedalus.com/).
See website for complete article licensing information.