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!
Do you want to watch TV? Grab the remote control and press the ON button. To mute the sound, press Mute. Simple. The service interfaces represent a binding contract between the service provider and the client. Ideally, the contract will be as generic as possible so that it can be flexible and you won’t need to change it for trivial reasons. On the other hand, you have to ensure the interface is complete and sufficiently specific to ensure there are no ambiguities during the request and the response.
The contract should not assume any explicit knowledge between the client and the service provider. In other words, the more abstracted and decoupled the interfaces are between the client and the server, the better. Imagine if every time you drove to a fast-food window you were expected to order the meal differently depending on who was taking the order.
Web services have gained quick acceptance because they rely on high level interfaces like XML. SOAP (Service Oriented Architecture Protocol) improves the situation even more by enforcing an interface view based upon WSDL (Web Services Description Language) as opposed to a view based upon data structures. Other approaches such as REST (Representational State Transfer) utilize the Web stack to provide suitable abstracted interfaces. However, regardless of the specific interface semantics, the point remains: a good interface should completely decouple the HOW a service provider works from the WHAT the service is offering. In the end, the client of the service doesn’t care whether the TV channel is changed via electronic circuitry or via a little gnome living inside the television (an uncomfortable situation for gnomes these days thanks to the advent of flat screens!).
But returning to our restaurant metaphor. . . You have probably been in one of those fast-food places where you can enter your order via a touch-screen. The result is that instead of having an $8/hour employee take your order, you have an $8/hour employer behind the Kiosk guiding you on how to input the order, and probably making you feel like an ignoramus. Unlike ordering your meal from a human being, using a touch-screen exposes some of the intrinsic processes used by the restaurant, and forces you to follow a specific, usually awkward flow, while ordering. This is one of the reasons touch-screens to order meals have failed to really take hold and, analogously, it’s a reason that an older “SOA Protocol” like CORBA (Common Object Request Broker Architecture) failed to catch-on as well. As with the touch-screen example, CORBA forced the client to match the server interface in a way that was not sufficiently transparent. Similarly, we cannot rightly consider remote object invocation protocols such as RMI (Remote Method Invocation) or the analogous RPC/XML (Remote Procedure Call with XML) to provide true SOA interfaces. These protocols force the client to make assumptions about the object methods and data types, while failing to properly hide the implementation of the service such as the way the called “service” represented by the object is constructed or initiated, and the way various data types are handled.
The difference between a service and a function is subtle, but the way to disambiguate it is clear: If the “function” being called is potentially required to be placed in a separate environment or can be provided by a separate vendor, then it should be defined as a service. Yes, RMI/Java APIs are okay for “local services”, but beware of this terminology. If you recall the transparency credo, you know that talking about “local” services is a mistake. If you intend to create a true service, then I suggest you expose it properly from its inception. As such, it should always be exposed as a decoupled service with a truly abstracted and portable interface.
Remote Object Invocation and other function-level interfaces fail to meet the implementation transparency credo required by SOA, making the resulting “service-less” SOA system as pointless as decaffeinated coffee or alcohol-free beer.
While some might argue the “merits” in using RMI or RMI-like protocols to improve SOA performance, this performance improvement, if any, comes at the cost of flexibility. Why? The moment you have to grow the system and try to convert the “local” service into a real service you are bound to face unnecessary decoupling work. This stage of the design process is not where we should be worrying about performance. Creating a function where a service is needed simply to avoid “the overhead” of XML or SOAP is not an appropriate way to design (in any case, said overhead can be minor when using coarse-grained services). Define the services you need first, and then you can focus on streamlining their performance.
Yes, there is a role and a place for RMI and Object Interfaces when you are certain you are creating a function and not a service. Functions are usually fine-grained and can certainly be used for specific intra-system calls to shared common objects. But the bottom-line is this: in case of doubt, use real SOA interfaces.
The beauty of respecting the transparency credo and enforcing the abstraction layer provided by properly laid down service interfaces is that you will then be in a position to leverage the tremendous powers that the underlying service framework provides in rapidly leveraging service ecosystems for the quick delivery of solutions.
Yes, these are the tenets that must be established to withstand the passage of time and to survive the challenging trials a complex project presents. Category I Tenets are not meant to vary over time, all the more reason for them to typically prescribe common-sense best practices. In many ways these tenets are so common-sense that their ‘motherhood and apple pie’ texture make them appear as though they are just a collection of distilled clichés. I suspect that when you read through the sample of Category I Tenets below, you’re going to say, “Duh! These are so obvious, why even bother to mention them?”
Well, we live in a world where many believe we didn’t really land on the Moon; where the so-called “birthers” refuse to acknowledge President Obama’s birth certificate, and where many think 9/11 was a self-inflicted government conspiracy. Irrationality loves the vacuum. Even if you discount all irrational arguments, the fact is there are a surprising number of cases where rational counter-points can be made to what seems to be a solid, “clearly-uncontestable” tenet.Even “obvious” tenets should be stated explicitly or you could risk someone, somewhere along the line, taking the counterview based on the validity of an isolated exception to the rule, or on the strength of an individual’s forceful opinion.
Take for instance the tenet, “Be Proactive; not Reactive”. This statement seems so obvious as to be unnecessary, but there are those who might argue that being reactive is a lower risk proposition, especially if agility to quickly catch-up with the competition’s first moves can be maintained. To them, the tenet should read, “Be reactive, but be quick to adapt to changing conditions”. In this light, the former tenet doesn’t sound so obvious anymore. Who knows, based on differing conditions it could well turn out that you transformation strategy should after all be reactive.
It’s important to state the Category I tenets openly and unabashedly. Following are a few sample Type I Tenets, representative of the kind of Category I Tenets you’ll need to define. Even though I am quite certain these tenets will hold water under a large number of conditions, they were selected under specific situations that might differ from yours. Clearly my list is not exhaustive, and yes, my lawyer also advices to remind you that you should be able assess these tenets in the light of your own transformation effort and use alternate or even opposite tenets as appropriate!
·Functionality requirements must be driven by the business requirements.
This statement simply reinforces the need to ensure that business is involved from the start in defining the specific features and priorities. However, getting the attention of business for what is essentially a strategic initiative can be a difficult undertaking. Business folks are typically immersed in addressing short-term issues. More significantly, typical business executives rarely focus on strategic technology issues (actually, that’s a good thing as this should be your responsibility; not theirs), so you will have to go the extra mile to extract and map the business requirements needed to create the technology plan.
·Be Architecture Driven; Not Vendor Driven.
This is a Zen-like “Be-the-Architecture”. Remember, we are talking about the transformation of IT elements that provide key competitive differentiators to your business.ERP is sufficiently commoditized so that most companies should be happy to follow the lead of vendors in this area. And yes, if you buy into the SAP or PeopleSoft views of the world for these particular IT domains, you will be just fine. Remember, however, that if you are to buy into the complete architecture view of a vendor for the development of your new core technology, you are making a generational commitment to that vendor—a commitment that ties your company to the vendor’s future for eons to come.I can’t tell you how many times I have come across companies that fully bought into a particular vendor’s architecture only to see that vendor go the way of the Dodo (an extinct bird—check it out in Wikipedia). What this tenet says is: design your architecture according to your company’s needs; make the architecture vendor-neutral, and then and only then approach vendors to ask them how they can help fulfill your vision.
·Use of off-the-shelf industry standards and products is preferred for all commodity-level elements
I’ve seen my share of companies who’ve spent an inordinate amount of time and effort developing their “own version of network protocols”, or their own “very cool, in-house version control system.” Unless there’s a clear cut reason for you develop a commodity component in-house, you’re better off having your team develop only those components that will create differentiating solutions. It’s wiser to focus on providing value-added features not readily available on the open market; the kind of features that leverage your company’s core competencies rather than divert resources to areas that can be easily met by a simple product purchase.
Now, this tenet might be seen as possibly contradicting the prior one (Become Architecture Driven; Not Vendor Driven); so let’s clarify: defining a “proprietary” architecture is in no ways wrong, but in fact is advisable.A bespoke architecture, however, does not presume the use of proprietary components. In fact, an architecture that’s well tailored to your needs will wisely identify the areas of focus for differentiated, value added development, and the areas and manners for interfacing off-the-shelf components.
·Architect from a Holistic Perspective
Don’t focus just on the needs of a particular business function or department.If the sales department requests a Prospect Tracking Tool, you could spend you energy defining the contact management tool requirements, designing the workflows and data bases involved, and defining a terrific prospect tracking tool. However, if you fail to think holistically by envisioning the synergies that can make the tool better you will be de-meriting the solution. What if you could tie in this solution to a more generic customer data base? What if you could gather customer purchase history and tie that information in with the tracking tool? Say, you were to find out that for the past two years youspent X amount of hours wooing a customer who generated only a minimal amount of business, while another customer, who had been contacted only a few times now represents 10% of your revenue? Wouldn’t you like to design a system capable of managing such a broad view?
Before you accuse me of over-scoping with a “what if all that’s needed is a tracking tool; nothing fancy or expensive!” I am not suggesting that you actually implement this type of holistic design. I’m suggesting that you architect the solution so that, should you decide to implement it, it will take into account the potential interactions with the rest of your system.
·Move to Service Oriented Architecture.
Enable an end-to-end, distributed service oriented framework that provides all necessary services independently of the underlying technical infrastructure. Arguably this is a Category II tenet, but given SOA’s establishment as the de-facto architecture pattern for modern systems, I think this is now a tenet that has attained a chisel-in-stone status.
·Minimize costs by driving reuse and convergence
This is like understanding the need for exercise, not smoking, and avoiding fats—obvious advice that’s rarely followed. Many choose time-to-market even with the added costs this heterogeneous solution demands.“You want a new campaign management solution? No problem! Let’s buy that super-expensive module from that company that invited us to the Ryder Cup last year! Later on, we’ll figure out some way to tie their customer data base in with ours!”
·Place automation of core business functionality in back-end systems
It is better to have the bulk of the capabilities served via back-end engines rather than designing a monolithic front-end that implements all functions. Many Web sites that have attained a large size organically are now suffering from limited scalability due to the failure of their designers to move the business logic to backend engines. The front end component should be limited to providing user interface capabilities such as interaction workflows and presentation level integration, and access the backend business processes via services.
·Keep the number of programming languages (and redundant technologies) to a minimum.
I am old enough to remember FORTRAN, a language widely used for scientific work. Then COBOL was invented by the great Grace Hopper to be the language of choice for “business applications”. Next came PL/I, an IBM specification that kind-of-combined COBOL with FORTRAN. As if PL/I were not bloated enough for the US Federal Government; the Department of Defense invented ADA, which is probably gathering dust in some of those old computers running the country’s nuclear silos (so it’s a good thing that ADA was a strongly typed language!). Meanwhile, a host of other languages sprouted-up like weeds in an unkempt backyard. We had Basic, LISP, Algol, Modula, Eiffel, and C, then C++, followed by Java which is “like C++ but with garbage collection and no pointers”; then came the wave of scripting languages that have come to look more and more like actual languages. Enter the Ruby vs Python debates.
I am certain that ten years from now, a similar passionate debate will be raging between followers of two as yet unknown languages (I don’t envision the day when computers will be programmed in plain English. Call me a nerd, but why we would we want to tell the computer to “Move money in the customer savings account to his checking account” when a simple Customer.TransferMoney(From, To, Amount) would do?)
Bottom line is that there are now literally thousands of computer languages (compiled and interpreted) out there.
You just don’t have to use them all!
The trouble with languages is that they tend to become the object of emotional preferences. It is natural that programmers familiar with a given language will gravitate toward that language. In large projects especially expect to be pressured to allow whatever programming languages your programmers’ desire. If there is an area where the proverbial stake needs to be sharpened, polished, and put into the ground, it is on this one!It is important that early on in the project you establish the tenet of using no more than two programming languages, and no more than one scripting language.
This tenet should also extend to the use of any other redundant technology: keep the number of J2EE Platforms to a minimum; keep the number of RDBMs to a minimum . . . You get the idea.
Now, I am not saying: “Have only one RDBMs solution”, or “Have only one Language”. Strive for simplicity, but not so much so that you become simplistic!
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.
