The outsourcing of parts of IT into Cloud has become more then a prognosis, it has become a reality. Moreover, it has become hype, a new ‘big thing’. Not many analysts and practitioners, though, have realized that this hype differs dramatically from all others: this one means that all previous hypes, intended to improve and modernize in-house IT have failed.
This time the ‘big solution’ to all modern IT problems is different and astonishingly ‘simple’ for Business – just outsource your IT, part by part, to a vendor or just the highest bidder, who promises to take care of it for you, and get rid of this hungry mouth eating your resources without any positive effect for your bottom line.
However, and I am very sorry to state it to Business, which has become so optimistic about this ‘simple’ solution after all these years of struggle with in-house IT, all is not so simple. Unfortunately, in real life there are no simple solutions, and the computing field is not the only one that demonstrates this sad but true fact. In Economical and Political Sciences there were also some simple solutions offered in the last century (mostly by the theories of Communism and National-Socialism), but they miserably (and fortunately) failed. On the other hand Capitalism and Democracy, which are pretty complicated, have prevailed. Computer Science (CS) does not offer simple solutions either. As we all know, the only lesson history teaches us is that nobody learns anything from history. However, for those who are trying to understand what has happened and why, it could be said that the main objective reason for each of the above-mentioned failures was that all these ‘simple’ solutions ignored the laws of their corresponding scientific disciplines, mentioned earlier in this article.
Computer Science (CS) does not offer simple solutions either. As we all know, the only lesson history teaches us is that nobody learns anything from history. However, for those who are trying to understand what has happened and why, it could be said that the main objective reason for each of the above-mentioned failures was that all these ‘simple’ solutions ignored the laws of their corresponding scientific disciplines, mentioned earlier in this article.
One thing, however, is really simple: either theoreticians and practitioners realize that they deal with underlying scientific discipline in their field, understand and implement the laws of this discipline and, hence, have chances to succeed or they do not and they fail.
Having successfully adopted the laws and approaches of CS for IT’s Design Phase of 90s (OOA&D, RUP, UML), IT as an industry has failed to do the same with the Architectural Phase approaches (BPM, ESB, SOA). The reason is simple: the Architectural Phase is dealing with much higher complexity, hence its laws much more complex, their understanding and correct implementation demands intellectual quality, proper education, hard work, and broad experience.
Unfortunately, historically this stage in computing came after the enormous boom in the field that happened at the end of the last century. It was great for the industry but had some downturns, because this boom brought to IT an equally enormous amount of half-educated or hastily re-educated people, sometimes with insufficient intellectual potential. The off-shoring of IT tasks to third-world countries obviously did not help from this point of view either, not because people there are stupid but because their learning curve naturally was 10 years behind the demands of CS.
The bubble of 90’s has burst, but could we honestly say that the people who kept their jobs were the most talented, rather than the most politically adjusted? Please understand me correctly: being politically adjusted is a very good quality, it just might not be the only good one. The result has led to today’s disaster: in-house Enterprise IT that en masse is unable to understand and correctly implement the adequate CS laws and methods.
The major software vendors, though, have, to a large extent, escaped this setback, being much more effective and objective in their hiring (and firing) practices, as well as much more receptive to CS advices. This higher density of talent and quality, as well as CS-awareness is the real, bottom-line reason why outsourcing of IT to vendors is more efficient, and hence, unavoidable.
So, it is not the case of angry Business, which motivating by ignorance wants to get rid of in-house IT, it is the case of in-house IT, which has failed to satisfy Business’s needs, because it has been unwilling or unable to understand the laws and methods of Computer Science for the Architectural Phase and implement them correctly.
Here are these scientific laws and rules.
Computer Science says that being in Architectural Phase means for an Enterprise that interrelations between Business & IT’s ‘moving parts’, which we called Enterprise Architecture (EA), have become no less important than the Design and Development of these parts.
While growing, every Enterprise inevitably creates its Architecture and makes it more and more complex. The difference in qualities of different EAs is that without care the structure that comes out of this growth resembles a jungle, while the one, which has been taken care of, looks more like landscaped parks or gardens.
The Cloud/SAAS outsourcing, as it happens now, happens mostly on an application-by-application basis (see, for example [ ]), meaning that different applications are being outsourced to different SAAS providers independently, without any architectural context. If an integration of these applications was an issue before, when they were part of the integral in-house IT, it becomes practically impossible after such outsourcing.
What Enterprise really outsources is its Architecture. Usually it is outsourced ‘As-Is’, without any accommodation, and this is the problem. Outsourcing parts of Architecture without proper preparation/transformation rips Architecture apart, which might be suicidal for Enterprise. And this is why. The main common problems the Architectural Enterprise has developed over last 10 years (the length of the Architectural period) are:1. High TCO of IT;2. Low business agility;3. High cost of exit from legacy technologies;
The careless outsourcing might partially and temporarily resolve only the first of them. The resolution applies only to the first problem, because overall architecture (i.e. inter-relations and inter-operation of the outsourced parts) becomes even less controllable and, less changeable. It is partial and temporary, because, by the same reason, any change soon becomes more costly. Moreover, due to the fact that Enterprise becomes tightly coupled to its SAAS providers then, if they, for example, triple the cost of services after the initial contract period or make the costs of enhancements astronomical, it would be hard for the Enterprise to change the providers, so the initial cost advantages might turn into a financial and business disaster.
So, what – outsourcing is bad and should be avoided? No, it is just not as simple as it seems, and only good when done intelligently. Intelligently here means that Enterprise should first prepare/transform its Architecture for outsourcing and only then do the outsourcing as a controllable Enterprise-wide and Architecturally-managed effort.
The CS’s requirements to such a transformation are:1. An Enterprise Service Bus (ESB) should be established as the common informational environment for future outsourced parts to exchange information;2. The Legacy applications should be transformed to Composite ones, and then to Business Service Domains (BSD) by exposing their functionality to ESB;3. The architectural priority of Business Process Flows (BPF) over any other artifacts should be established. It is because the only thing that Enterprise is doing is executing its Business Model via Business Processes. So, only BPFs can tell if some specific service or data is needed. There is no other way to learn it. 4. The outsourcing of BPs should be done carefully – they are Enterprise’s intellectual property.5. BPFs should be decoupled as service requestors from BSDs as service providers through ESB; BSD-to-BSD calls should be avoided if possible;
This is what is called Enterprise Architectural Transformation (EAT). EAT Frameworks, like, for example, ESOAF, which represents a practical month-by-month, group-by-group, stage-by-stage guide explaining: Who is doing What, Why, Where, How, and When in the Enterprise during EAT, are developed to ease this transformation for Enterprise.
The Final, Desired State of in-house Enterprise IT is called in ESOAF ‘Elegant Enterprise’. This State at the same time is also the perfect Initial Architectural State for the intelligent outsourcing transformation. What makes it perfect is:1. It allows for BSD-based step-by step uncoupled outsourcing, based on ESB, even if ESB itself is outsourced;2. Which is good, because it allows Enterprise to continue orchestrating its BSDs; remember, outsourced BSDs cannot be integrated, but they can be orchestrated;3. Which, in turn, allows Enterprise to be uncoupled from its SAAS providers, and to more easily replace them should any problem occurs;4. It allows, for the creation of IT As A Service (ITAAS) or ‘Heavenly Enterprise’ – Cloud/SAAS-based, post-in-house IT, Business-controlled Enterprise;
As you can see, BPM/ESB/SOA-based Enterprise Architecture does not go anywhere with outsourcing. Moreover, it becomes critically important to keep the outsourced IT efficient and under control.
1 John Jainschigg. Serving Up SAAS. Baseline Magazine. July 2008.Issue 086, pp. 20-27.
