A common approach to explaining the benefits of Enterprise Architecture is to draw two diagrams: one that shows a complicated mess of interconnections, and one that shows a nicely layered set of blocks. Something like this one, which came from some consultants:
I've never felt entirely happy with this approach. Yes, we do want to remove as much of the needless complexity and ad-hoc design that litters the existing architecture. Yes, we do want to simplify the architecture and make it more consistent and intelligible. But the simplicity of the block diagram shown here is unobtainable in the vast majority of real enterprises. We have a mixture of in-house development and different third-party systems, some hosted in-house, some on cloud infrastructure and some accessed as software-as-a-service. For all the talk of standards, vendors use different authentication systems, different integration systems, and different user interfaces.
So the simple block diagram is, basically, a lie. What's more, it gives senior management the impression that we can make IT simple, when IT systems are actually some of the most complicated things mankind has ever built. It also gives the impression that buying an enterprise service bus, or data integration software, or cloud hosting, will solve all our problems, whereas they are just part of any solution. It is setting us up for failure and for making everyone unhappy.
We can do better by being more specific. It's perfectly reasonable to draw the "as-is" and "to-be" architectures, if we use the same level of detail and the same type of presentation. (Behind the scenes we should use a modelling language; we can translate that into a simplified view for senior management). We should focus on specific changes, not grand generalities. This approach will take more work and promise less, but will deliver more. It's more honest and defines a path to success.
I've never felt entirely happy with this approach. Yes, we do want to remove as much of the needless complexity and ad-hoc design that litters the existing architecture. Yes, we do want to simplify the architecture and make it more consistent and intelligible. But the simplicity of the block diagram shown here is unobtainable in the vast majority of real enterprises. We have a mixture of in-house development and different third-party systems, some hosted in-house, some on cloud infrastructure and some accessed as software-as-a-service. For all the talk of standards, vendors use different authentication systems, different integration systems, and different user interfaces.
So the simple block diagram is, basically, a lie. What's more, it gives senior management the impression that we can make IT simple, when IT systems are actually some of the most complicated things mankind has ever built. It also gives the impression that buying an enterprise service bus, or data integration software, or cloud hosting, will solve all our problems, whereas they are just part of any solution. It is setting us up for failure and for making everyone unhappy.
We can do better by being more specific. It's perfectly reasonable to draw the "as-is" and "to-be" architectures, if we use the same level of detail and the same type of presentation. (Behind the scenes we should use a modelling language; we can translate that into a simplified view for senior management). We should focus on specific changes, not grand generalities. This approach will take more work and promise less, but will deliver more. It's more honest and defines a path to success.
Comments