Enterprise Architecture (EA) has been around for about 25 years, and has been the subject of criticism amidst the IT Community ever since. Into some extent I can relate with some concerns, however the line of argumentation is flawed and exemplified with wrong implementations of EA practice.
Some considerations sometimes overlooked:
1. The concept of EA relates to both the process and to the product of its work.
EA is sometimes perceived as a set of slides, diagrams and blue-prints that obey to numerous standards and guidelines, stating recommendations for the implementation of Information Systems.
But in fact, EA encompasses a governance framework to create and maintain the IT Landscape of one organization. From requirement to implementation.
2. The main driver in EA is not the technology but the business capability that one organization needs to maintain in order to run efficiently.
A holistic view of the Organization Business is required in order to perform a true EA endeavor. It must not be an IT-Centric endeavor; it must be closely tangled with strategic planning.
In reality many improvement programs start with technology application strategies, like SOA or Cloud Adoption and hope to improve the overall organization problems. EA starts on the other end of the spectrum, learning the business context and problems before jumping to any sort of solution.
A funny example from the “The Tao of Programming”, states that if you ask a programmer to develop a financial package and let him unsupervised for a couple of weeks, what you end up with is: “screen editor, a set of generalized graphics routines, and an artificial intelligence interface, but not the slightest hint of anything financial. ”
3. EA can be applied only to a subset of the Organization
Not every aspect of the organization has to be modeled by an EA Office. The EA Capability should be tailored, and take into account the internal department competences. If not, the red-tape peril escalates, becoming a bottleneck for an agile environment.
A good example that I took part was the early scoping between BSS (Business Support Systems) and OSS (Operational Support Systems) for an EA engagement on a Cloud Provider. The OSS were not part of the scope, mainly due to an extremely experienced Engineering Department inside the organization. Only the Integration of OSS information with the BSS systems was covered by EA.
4. EA has to be top-down
Any major transformation has to have: business case, sponsor and budget.
The start, middle and end of an architecture cycle are about getting approval and commitment. Thus the recommended approach is top-down, starting at CxO level trying to translate their vision and problems into valuable IT-Requirements.
Conclusion:
I recognize that many EA efforts have failed. However not due to EA as a practice, but because of the undertaken approach. On the following years EA will become more vital than ever to any organization that wishes to start a digital transformation of business. It can't be overlooked.
Share your thoughts on this subject!
1. The concept of EA relates to both the process and to the product of its work.
EA is sometimes perceived as a set of slides, diagrams and blue-prints that obey to numerous standards and guidelines, stating recommendations for the implementation of Information Systems.
But in fact, EA encompasses a governance framework to create and maintain the IT Landscape of one organization. From requirement to implementation.
2. The main driver in EA is not the technology but the business capability that one organization needs to maintain in order to run efficiently.
A holistic view of the Organization Business is required in order to perform a true EA endeavor. It must not be an IT-Centric endeavor; it must be closely tangled with strategic planning.
In reality many improvement programs start with technology application strategies, like SOA or Cloud Adoption and hope to improve the overall organization problems. EA starts on the other end of the spectrum, learning the business context and problems before jumping to any sort of solution.
A funny example from the “The Tao of Programming”, states that if you ask a programmer to develop a financial package and let him unsupervised for a couple of weeks, what you end up with is: “screen editor, a set of generalized graphics routines, and an artificial intelligence interface, but not the slightest hint of anything financial. ”
3. EA can be applied only to a subset of the Organization
Not every aspect of the organization has to be modeled by an EA Office. The EA Capability should be tailored, and take into account the internal department competences. If not, the red-tape peril escalates, becoming a bottleneck for an agile environment.
A good example that I took part was the early scoping between BSS (Business Support Systems) and OSS (Operational Support Systems) for an EA engagement on a Cloud Provider. The OSS were not part of the scope, mainly due to an extremely experienced Engineering Department inside the organization. Only the Integration of OSS information with the BSS systems was covered by EA.
4. EA has to be top-down
Any major transformation has to have: business case, sponsor and budget.
The start, middle and end of an architecture cycle are about getting approval and commitment. Thus the recommended approach is top-down, starting at CxO level trying to translate their vision and problems into valuable IT-Requirements.
Conclusion:
I recognize that many EA efforts have failed. However not due to EA as a practice, but because of the undertaken approach. On the following years EA will become more vital than ever to any organization that wishes to start a digital transformation of business. It can't be overlooked.
Share your thoughts on this subject!