What the Programmer needs to know about Architecture (SOA 3)

As I have written before, programming and architecture are different skills, and the architect need not be a great programmer. Software Architects work primarily in models, patterns and process, not code. The chief skill of the software architect needs to be in expressing the underlying business purpose as a service.

It is easy for the programmer to see such statements and think “What a load of Rubbish!” There have been some notable rants written against the misuse of the words “Architecture”, “Enterprise” and “Service” (see caustictech.typepad.com). Many claim the words with no idea what they mean. For others, the friction is because the architects interfere with the solitary programmer’s desire to just get things done by himself, as he sees fit. It is easy, but not correct.

But what if you are a programmer, coding happily with no interest in architecture? How should Service Architecture affect your world? I am excluding the trivial example, in that you need to be able to read the interface documents prepared by the system architect.

The programmer should know:

• What is architecture concerned with? Can I recognize the demands of architecture and so work to strengthen rather than weaken architecture? Can I resist inappropriate requests that will cause brittle integration to harm the enterprise later?
• How should the existing monolithic applications that I work with every day fail in part because of the lack of architecture? Can I recognize when they should be broken up. Can I recognize when multiple services are inappropriately bundled so I can get ready to move in the right direction.
• What if my best work should not be written? A coder should learn to recognize when difficult code is substituting for good architecture. A code jockey should recognize when the problem would be solved better by adding an architect.
• Is my best code maintainable? As a manager, I know that a job description that requires sainthood from the employee is poorly written. The same applies when an application requires virtuoso coding. An old lemma is that it is twice as difficult to debug as it is to code, so you had better not be programming at the limit of your abilities…

When he understands and acts on these issues, the Coder can stay safely away from the Architect.

Next: How Service and Security support and extend each other

Services and Mouse Traps

Did anyone see the article on an IT consultant SOA enabling his house? It ran while I was on vacation and I saw it in passing; now I cannot find it.

The story ran something like

“IBM Consultant and OASIS committee member used service oriented architecture to monitor every part of his house. He even service-enabled the mouse traps in his barn, using sound sensors to tally each time a mouse trap was sprung”

Or so I recall.

 
I would very much appreciate a pointer to the actual story…

Applying Service Orientation to Engineered Systems (SOA 2)

The world of the engineered system always tend to get stuck on the procedure side. The best engineers are known because they develop a superior process; it is no surprise that they come to believe that the process is what people want. This leads to long sales cycles, and uncommunicative systems in sterile silos. The result is rent-seeking industries that cannot perceive the true value they might offer their customers, and thus have trouble convincing their customers of the new value they might add.

In the last post, I claimed that Dell suffered by outsourced its tech support process rather than its tech support service. End-user tech support is notoriously difficult to develop metrics for. If you track agent calls per hour, customers will be rushed through their calls without regard for their understanding or satisfaction. If you reward the first agent for solving the problem without calling for help, then there will be many mysterious disconnects during phone transfers. Under some metrics, it is better not to answer the phone at 4:30 than risk having an uncompleted call at 5:00. I know one site in which the agents routinely recorded all notes on paper, allowing them to enter and complete service calls in seconds. Be careful what you measure, because you will get what you measure.

The best out-sourcing (or in-sourcing) of any business function is when people know exactly what service they want, or what service they can provide.

Kevin Sample has told me that the HVAC systems for chain drug stores provide three services, and might be provided as three systems. The open floor’s service is the economic provision of a healthy and comfortable environment. The service provided in the pharmacy area is keeping the drugs stable; this might require colder temperatures, lower humidity, and less variance, whether the store is open or closed, than the first service. The service provided by the store’s warehouse area, as relayed to me by more than one experienced hand, is “Don’t melt the chocolate!”

What is most interesting about these three missions is that not one of them mentions any component of the system, or demand limiting, or load control, or even temperature. Each of those metrics or processes might be interesting, but only as subordinated to the primary service. When I am speaking, my shorthand for this is “Each system has a mission, and its primary job is to defend that mission no matter what it is asked to do.

Load control is, then subordinate to the mission, that is to say the service. Within the mission, each of these systems is able to respond to demand limiting or demand response requests. The more intelligent system will understand how to anticipate time-based load control by making adjustments in advance. A simple way to do this might be by over-cooling space early in the day when power is cheap.

Recently Dr. Bob Smith described to me a failure caused by exposing process rather than service. Bob lives in Huntington Beach, and California had some very hot days in early September. A hospital responded by turning off the air conditioning in the clinical areas, with a scheduled resumption at 8:00 Monday morning. It took more than half the day to get the spaces properly conditioned. During those 6 hours, doctors and nurses worked at greatly reduced efficiency. The mission costs to the hospital were probably greater than the energy costs saved. As an added detriment, the cooling was performed during the day, at day-time costs, under day-time heat load.

If the hospital systems had been better defined as a service, the same request would have been “prepare clinical spaces to be in operation at 8:00 AM”, rather than “Turn on at 8:00 AM.” The system itself, with domain knowledge greater than any possessed by the hospital administration, would have decided when to turn on. Using extant outside air temperature sensors, internal temperature sensors, humidity sensors, and even the live electricity pricing, the system would have decided when and how to return the clinical areas to optimum conditions.

Next: How Service Architectures change what the programmer needs to know.

Software Architects and Architecture (SOA 1)

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.