BPM-EAI

Even though the world around us gives us a good amount of reference Architectures, organizations learn the hard way to come to a definitive IT implementations.

Lets take some examples or reference constructs:

1. One size fits all Architecture is doomed for failure in real world as well as the technology world. A good architect designs the building based on customer’s requirement as well as considering the purpose, place and environment conditions. For e.g. Manhattan is appropriate for having the largest number of skyscrapers but no one would think of replicating that in Venice. The bedrock based on Manhattan Schist helps the foundations of tall buildings making Manhattan unique in the world. Similarly Venice is a beautiful city for what it is. The same principle holds good in Systems Integration. We cannot have an integration message bus based on the principles of broadcast just because it is one of the ways or a product vendor sold it. The business requirements, the integration requirements and how the communication needs to happen with other non functional factors determine the technology Architecture.

2. Foundation should be built with end state in mind. This is probably the most crucial one as everyone misses this in IT Architecture. For e.g. Adding even a single floor on top of the 108th floor of Willis Tower could break down the building; Adding an extra lane in the existing roads of central London will require restructuring the associated buildings. Similarly while creating the technology platform for BPM (no. of users, procedures), SOA (no. of services, service assemblies), EAI/ESB (no. of applications to be integrated, no of common services to be part of ESB) should be known at the time of Architecture. Assuming that this could be extensible just through horizontal or vertical scaling at a later point is not really a good idea.

3. Plan for maintenance. There is no building, road or dam in the world that doesn’t require regular maintenance. Obviously it is planned and put in operation even before implementation.

4. Define the end of life. This is more relevant to the IT where Moore’s law comes into effect and organizations need to keep their IT hardware and software updated to be for the simple reason of being best in the business. Every IT Solution thus need to have a life span defined.

5. Patterns do help. Just like there are highways, expressways, main roads, side roads, streets, boulevards, parkways to make a transportation system for connecting different cities or within cities - similar patterns can be put in place for EAI Architecture. One of the common mistakes is using the Enteprise Bus (highway) for all messaging needs. There needs to be a primary, secondary, tertiary and quaternary layers for different messaging needs mapping to functional and non-functional requirements.

There are many other such patterns, designs that are successful in real world that can easily be mapped to technology world and make the IT as robust as it is expected.