A dirty IT architecture may not be such a bad thing
Simplifying your architecture looks good on paper, but is it worth the effort?
Published 06:00, 16 April 12
For some time both CTOs and architects have looked at enterprise architectures and sought to simplify their portfolio of applications. This simplification is driven by the needs to reduce the costs of multiple platforms driven largely through duplication.
Duplication often occurs because two areas of the business had very separate 'business needs' but both needs had been met by a 'technical solution', for example a business process management tool or some integration technology. Sometimes the duplication is a smaller element of the overall solution like a rules engine or user security solution.
Having been in that position it’s quite easy to look at an enterprise and say "we only need one BPM solution, one integration platform, one rules engine". As most architects know though, these separations aren’t that easy to make, because even some of these have overlaps. For example, you will find rules in integration technology as well as business process management and content management (and probably many other places too). The notion of users, roles and permissions is often required in multiple locations also.
Getting into the detail of simplification, it’s not always possible to eradicate duplication altogether, and quite often it won’t make financial sense to build a solution from a 'toolbox' of components.
Often the risk of having to build a business solution from ground up, even with using these tools, is too great and the business prefer to de-risk implementation with a packaged implementation. This packaged solution in itself may have a number of these components, but the advantage is they are pre-integrated to provide the business with what they need.
For some components duplication may be okay, if a federated approach can be taken. For example, in the case of user management it is possible to have multiple user management solutions, that are then federated so a 'single view of users' can be achieved. Similar approaches can be achieved for document management, but in the case of process management I believe this has been far less successful.
Another issue often faced in simplification is that the tools often have a particular strength and therefore weaknesses in other areas of their solution. For example, Sharepoint is great on site management and content management, but poorer on creating enterprise applications. Hence a decision has to be made as to whether the tool’s weaknesses are enough of an issue to necessitate buying an alternative, or whether workarounds can be used to complement the tool.
The technical task of simplification is not a simple problem in itself. From bitter experience, this decision is most often made on the basis of who owns the budget rather than the available technologies and what is good for the enterprise as a whole.