Many who have been around long enough to remember the good old days of data processing may still long for the simplicity and maturity of centrally located mainframes which could be accessed via a simple line protocol from basic screen devices and keyboards at each client location. Older “dumb-terminals”, such as Teletypes, ICOT and 3270 devices simply captured the keystrokes which were then duly sent to the mainframe either in character-by-character mode or in blocks. The mainframe then centrally formatted the response which was then displayed by the access device in the same blind manner Charlie Chaplin hammered widgets in the assembly line of Modern Times.
For a period of time, with the advent of the PC back in the 80’s, a debate ensued about the idea of moving all processing to client devices. For a while, the pendulum swung towards having PCs do the computations, earning them the “fat clients” moniker. After enjoying the exhilarating freedom of not having to depend on the DP priesthood behind the central mainframe glass house, local IT departments began to learn what we all are supposed to have learned during our teenage years: with freedom come responsibilities. As it turned out, trying to keep PC software current with the never-ending stream of versions updates and configuration changes or trying to enforce corporate policies in this type of distributed environment, no matter how flimsy, soon became a Nightmare on IT Street.
Newton said it best: for every action there is always a reaction. Soon voices from the “other-side-of-the-pendulum” began to be heard. Mainly as a strategy to counter Microsoft which in the early nineties was still the eight-hundred pound gorilla that Google is today, the folks at Sun Microsystems began pushing for the “Network Computer” concept. This was in reality a cry for the dumb terminals of yore; only this time designating the Java Virtual Machine as the soul of the distributed machine. To be fair, given the maintenance burden presented by millions of PCs requiring continuous Windows upgrades, these network computers did make some sense. After all, network computers were actually capable of executing applications autonomously from the central system and thus were not strictly the same as old-fashioned “dumb-terminals”.
In the end, the pendulum did swing back towards Thin Clients. Enter the original Web Browser. This time the appeal of Web Browsers was that thanks to Tim Bernes-Lee, the inventor of the Web, they accelerated the convergence of technology platforms around a standardized access layer. Whereas in the past each company might have used proprietary access technologies, or even proprietary interfaces, web browsers became a de-facto standard. The disadvantage was that, well, we were once again dealing with a very limited set of client level capabilities. The narrow presentation options provided by HTML limited the interface usability. Java Applets solved this constraint somewhat but then ironically increased the “thickness” of the client as programmers tended to put more processing within the Applet. Thankfully we are now reaching the point where we can strike the proper balance between “thinness” and “thickness” via the use of Cascading Style Sheets and, more recently, Ajax and Dojo.
Now, a word about two of today’s most popular client access solutions: Proprietary Multimedia extensions, such as Macromedia Flash and what I refer to as “Dumb Terminal” emulators, such as Citrix. Using Macromedia Flash is great if you are interested in displaying cool animations, enhanced graphics and such. It is fine to use languages such as Action Script for basic input field verification and simple interface manipulation (i.e. sorting fields for presentation, etc.), but writing any sort of business logic with these languages is an invitation to create code that will be very difficult to maintain. Business logic should always be contained in well-defined applications, ideally located in a server under proper operational management.
Technologies such as Citrix basically allow the execution of “Fat Client” applications under a “Thin Client” framework by “teleporting” the Windows-based input and output under the control of a remote browser. My experience is that this approach makes sense only under very specific tactical or niche needs such as during migrations or when you need to make a rare Windows-based application available to remote locations that lack the ability to host the software. Citrix software has been used successfully to enable rich interfaces for web-based meeting applications (GoToMeeting) when there is a need to display a user’s desktop environment via a browser, or when users want to exercise remote control of their own desktops. Other than in these special cases, I recommend not basing the core of your client strategy around these types of dedicated technologies. Remember, when it comes to IT Transformation you should favor open standards and the use of tools that are based on sound architecture principles rather than on strong vendor products.
As a close to this discussion on Access technologies; just as we no longer debate the merits of one networking technology over another, network technologies have become commoditized. I suspect we will soon move the discussion of Access technologies to a higher level, rather than debating the specific enabling technology to be used. Access-level enabling technologies such as Ajax and others are becoming commodity standards that will support a variety of future access devices in a very seamless fashion. So, pull out your mobile phone, your electronic book reader, and bring your Netbook, or laptop, or access your old faithful PC, or turn on your videogame machine, if you don’t want to fetch your HDTV remote control. It behooves you in this new world of IT Transformation to make it all work just the same!
It’s time to move on to the more detailed Level IIarchitecture. 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.
This blog covers the practical techniques, trials and tribulations associated with the transformation of IT systems from legacy technologies to systems using SOA and modern open systems. I also include the occasional interlude with rants about technology in general.
About Me
Name: Israel del Rio
Location: Atlanta, GA, United States
Israel has been recognized by Computerworld as one of their Premiere 100 IT honorees. Israel is a business and technology leader who has contributed the technology vision as key strategist and designer behind the enterprise technology roadmaps of large hospitality and travel companies. Israel has also have developed and deployed various mission-critical systems and in the process, he's been instrumental in creating and building effective and skilled development organizations.
