Looking at history, where networks are created and can collapse, we need to learn in IT what the risk are of our attempts to unite the IT landscape with Service Orientation (SOA) and Event Driven Architecture (EDA). Examples in the financial world and the utility market should be a warning for IT of what could hit us. This calls for craftmanship of people in our profession who have the ability to look cross borders and control by means of Governance, in Design AND in Run time.
One example of a collapsing network is the current ongoing subprime mortgage crisis which still creates waves of unemployments, closing of companies an costing a lot of money. It is caused by globalization of the financial world, a would be believe that house prices would never go down, the growing dependancies of markets and the lack of control. At one point is became clear that the fundament of the economic rise, the ever increasing house price, was not a certainty anymore, and the network collapsed.
Another example is in the utility market. On august 14th, 2003 a disruption of the energy grid caused a blackout in the North Eastern part of the US and Canada, and hit 10M people. It started as massive power fluctuation in New York state and, in no time, affected all the areas. Here one flaw in one part of the energy grid caused the collapse of a very large part of the energy grid.
In IT we come from silo based architectures, every functionality (or set of functionalities) is contained in one silo, which may have integration points with other parts in the enterprise but stands essentially on its own. When one of these silos goes down it can cause a major problem for the enterprise, loss of sales, the going down of an essential production process, and in the end money and reputation damage. But at this point, it would NOT cause a cascading domino effect on other systems or enterprises. The promise of the SOA and EDA is the network of applications where everything can be connected and reused. Especially the reuse part can be the risk part, reuse with no insight in the relations can cause Single Points of Failures.
We are creating the power grid of applications for the future, that makes us responsible for making the right choices now.
One of these choices is to know the dependancies of the system components, for both in Design and in Run time.
At Design time, we need to be able to quickly identify all the dependencies in our landscape. This includes both the application types like custom build (based upon all types of technologies), package based, legacy and integration components. With the ultimate wish to be able to create an impact analysis list based upon all the touched components with just one push one the button. Another decision which is made at Design time, is whether we´d like to reuse an existing component, elsewhere in the enterprise landscape or even outside, and what the impact is if that (reused) component goes down. Based on that risk analysis we can decide whether to reuse that component or build it ourselves.
At Run time we need to have insight in the inter relations between all deployed components, and identify possible risk areas, for instance a service which is used by an ever increasing amount of applications.
Where should we start? In most environments people start of with Excel sheets, which in no time are not usable anymore because of the complexity, which calls for the need for proper Governance tooling (or at the basis a dependancy tracking tool). When you start with a Governance tool the environment is, of course, empty. Loading all the components and dependancies in your environment is time consuming and costly. This is the major problem why dependancy tracking tool, (SOA) Governance tools and Service Repositories are hard to start with in enterprises. The Business case at start is way too costly, even though we all know that on the long term it is essential for getting a grip on you IT environment. A diffentiator in this market will be the option to load an existing environment into the dependancy tracking tool repository.
2 opmerkingen:
Good article!
In essence, designing a SOA isn't much different from making a system design. Where functionalities used to take the form of functions, they now are (reusable or not) services, which are just interfaces to existing backend functionalities (inside an enterprise) or interfaces to outside (web) services
In the old days, a system or application was one solid rock, maybe relying on a few external interfaces for some batch-processing
Outage would simply manifest itself system-wide, it would either work in total or not at all
BPM already introduced the risk of great dependency, where an enterprise-wide process would consist of multiple applications and systems, each representing a potential single point of failure
In my opinion SOA doesn't add much to these dependencies, nor does EDA. SOA introduces a larger scale, and thus more complexity; EDA introduces faster response time, and thus smarter and faster connections
Personally I can't imagine SOA without and enterprise-wide integration solution resembling a canonical model under strict Governance, nor can I imagine EDA without an enterprise-wide queueing system for nano-second response
Anyway, off to the question: where should we start? I use mindmaps a lot for this kind of activities, as they're really great for focussing on one part of a complex whole, while mapping a whole chain of interdependent activities / processes
What about the components themselves, whether package-based, tailormade, external or internal? Well, as in infrastructure, redundancy can be the answer. However, dynamics in infrastructure are a lot less than in business application - maintaining redundant business components might just not be a wise investment
Standardisation on the technical side will help us all a lot. Although the example of a power grid failure affecting millions of people, shows that technical standardisation is far from enough, an ordinary fallback-scenario might have helped in this case. The real challenge will be business standardisation, i.e. looking far enough ahead to be able to keep up with internal and external business demands an IT-solution changes
Tools for all this? You can only tool what can be tooled, same as you can only offshore tasks and products that are specced clear enough. There will never be a tool that will fit upon the current (and future) diversity of applications and systems making up the IT landscape of an enterprise. Not even if your whole world consists of SAP or Oracle alone (if that were possible anyway)
Lately I strongly plea for awareness of and attention for the fact that businesses are being driven by business exceptions rather than by business rules. Ever increasing time-to-market, cost-effectiveness and stronger competition create a greater demand on flexibility i.e. deviation from business as usual
True enterprise collaboration and organisation is where we have to start, getting rid of the silos and political islands that prevent an company from acting as one
So to summarize your blog: We need an overall insight in our IT assets and their usage (agreed contracts and the usage of them).
I could not agree more ;)
But this has always been the case, also when developing SILO based applications. With SOA, ROA, EDA, SAAS etc. the scope of IT is becoming more narrow. Where we governed a whole application, we now govern the services of the application.
So, the amount of information particles to govern is rising dramatically.
UDDI, WADL etc. are good initiatives to standardize and administrate services, but they are not sufficient enough.
See it as an opportunity!
Een reactie posten