SOA as the Solution Architecture
It’s time to move on to the more detailed Level II architecture. There are myriads of variations in Level II architectures and most have probably been tried in the past. Every few years or so, you wake up to find new technologies that promise to solve all your IT ailments: high level languages, structure programming, fourth generation programming, CASE Tools, Object Oriented Programming and an ever-expanding list of software development methodologies. However, given that this is the dawn of a new millennium and that we have over six decades of commercial computing under our belts, I would suggest that not planning to adopt SOA (Service oriented Architecture) for a new system would be like planning to build a house using straw and mud. Yes, there might be reasons for preferring to build a primitive hut (as a part of a movie set, perhaps?), but in general I’d rather build a house using modern construction materials. Wouldn’t you?
Defining a high level architecture these days is all about adapting SOA precepts to support the chosen architecture. Even though SOA can aid in simplifying the definition of the Level II architecture, you and your team still have to make the key decisions related to SOA-specific choices. Remember, this is the stage where the architecture moves from abstract to more pragmatic levels. With Level II you will still be high enough up so that you won’t need to worry about negotiating the ground level, but at thirty-thousand feet you have to keep a watch out for weather patterns. It is in this stage that you can better discern the horizon and where true innovation can be applied with unique solutions that can ultimately serve as key success differentiators in the ultimate deliverable.
The first thing to keep in mind is that SOA is about simplifying the business process automation and not about introducing technology for technology’s sake.
A friend of mine related this anecdote after attending a ceremony celebrating the activation of the first automated phone exchange in a small town in Mexico. As the mayor gave a glowing discourse on how the town was finally “entering the 20th century” and people would now be able to automatically place calls simply by dialing the numbers on their phone, an elderly woman sitting next to him complained, “Automatic? This ain’t automatic! Automatic was when I lifted the receiver and asked Maria, the switchboard lady, to connect me to my daughter!”
She was right. From a user’s perspective, all that matters is the ability to articulate a need in a simple way, and then have the need satisfied by the appropriate service. Alas, this woman will have to wait many years before she once again receives the same level of service she received from Maria. Maybe if she (or her grandkids) programmed her cell phone, she could once again connect to her daughter simply by speaking her name. However, if she ever wanted a connection by voicing something like, “connect me to someone who can fix my stove”, this would require the emergence of software that can truly understand natural-language and take intelligent action (don’t get me started with the so-called Interactive Voice recognition systems of today!).
The beauty of thinking in terms of services is that you can avoid getting bogged down by how the service is provided. The manner in which the service is provided should be, in the end, immaterial to the person requesting the service. What it does matter is having a well defined interface to the service be well defined. If you order a meal in a language that is not understood by the waiter, then you can be assured the request either won’t be met or that you will get served a dish full of proteins and fats of unknown origins (something like this actually happened to me while in Hong Kong, after wrongly assuming I had ordered chicken!)
How then do we define SOA? Simply stated, SOA deals with the ability to ask a system to do something (typically a coarse-grained business or system process) without having to tell it HOW to do it. Think about it, when you go to a restaurant and order a dish from the menu in the correct language, you are applying SOA principles. SOA is about abstracting the request so that the business need can be posed directly to the system via the use of a proper interface request.
In fact, SOA is nothing new. From my perspective, Service Oriented Architecture was actually invented more than ten thousand years ago with the advent of modern civilization. The SOA inventor is unknown, but most assuredly was some lazy bum trying his best (let’s face it folks . . . it was a he!) to avoid work and pass on responsibilities to others. Specialization resulted in people becoming more competent in their chores and the framework of rules and processes needed to facilitate this delineation of responsibilities became part of the societal laws we have today. Back then you had a merchant asking a scribe to log a transaction, or a king requesting a priest to plead his case to the gods, or a man of commerce paying someone to carry his produce. Agriculture, war, religion, the construction of temples and edifices, all the core activities we associate with modern human endeavors, are the results of someone doing another one’s bidding along the concepts we now refer to as Service Oriented Architecture. Once SOA became firmly entrenched, there was no turning back. SOA became the paradigm of civilization. As it expanded, it created the specializations and professions we see in today’s world.
So, why wasn’t SOA used in IT systems from the start?
Earlier generations of computer technology did not have enough “juice” to support SOA. RAM was too expensive, disks were too slow, and communication speeds were hilariously sluggish (300 bauds[1] was super-fast, and data at that speed would have taken you something like twenty-four hours to download just one song from, say, The Gabe Dixon band—one of my favorites). Still, information systems had to support business systems and business needed IT; so an implicit compromise was struck. When it came to IT, SOA was abandoned in favor of an approach that forced business to adapt to computers rather than the other way around. For example, computers did not have sufficient storage space to store dates, so only the last two digits of a year were stored. Computers didn’t have the ability to present information in plain English. No problem, only abbreviated codes, upper-case text, and cryptic commands were used.
The result is that traditional IT quickly devolved into an assemblage of monolithic processes, inflexible data schemas, and unfriendly interfaces. Eventually, as a consequence of Moore’s Law, computers became more and more powerful, and more capable of tackling increasingly complex tasks. We have now come full circle. Instead of having to adapt to the computer’s limitations, it is the computers that are now expected to adjust to human ways of interaction and even to handle high-level questions and processes. Computers can now provide natural interfaces, follow complex heuristic-driven reasoning logic, and seamlessly tap large amounts of stored information; all in real-time. SOA is the natural way to architect systems, and its use in computer systems is the result of finally being able to effectively mirror business processes with technology thanks to the arrival of powerful computers, cheaper storage, and faster networks. Now, effectively doesn’t mean efficiently. Applying SOA conveys a certain acceptance that we can afford to “waste” computer resources to achieve the flexibility and transparency advantages SOA provides (more on this next week)—something similar to the way we have accepted the performance impact of using a higher level language over machine language programming.
Now, don’t get me wrong, badly implemented SOA can result in major costly failures. Just because we can now afford computational power to better mirror business processes doesn’t mean that resources are infinite, that budgets are boundless, and that the laws of physics can be suspended. In fact, SOA gives you flexibility, and we all know that with flexibility comes plenty more ways to screw up! SOA is not a panacea, but when properly applied, our computer systems can become part of the SOA future, just as SOA has always been a part of our past.
Labels: Architecture, Business Rules, Gabe Dixon Band, IT, Languages, Level II, SOA, Technology
posted by IT Transformation with SOA @ 1:08 PM
