There is no steady state for EA function, as EA has unenviable job akin to converting a propellar driven aircraft into a jet aircraft, while flying. And it does not stop there, by the time EA managed to turn into a jet aircraft, new scramjet is already available and waiting for being adopted.
To cope with this constant churn, the usage of EA frameworks is widespread. But, as I had pointed in my earlier post that results on ground are only thing appreciated by end-users. This post by Tom re-emphasised the point about operationalising the Enterprise Architecture as had this post by Sam. Operationalisation of EA is what is capable of producing the results, no matter what framework was used to structure thinking and what artefacts were built. Unfortunately after spending lot of bandwidth in think and build activities, there is little spare bandwidth available for operationlising the EA.
In a large enterprise, structuring the business IT change portfolio is a great opportunity for EA function to make sure EA is operationalised. Its where the lack of bandwidth affects the EA function. Somehow this important activity uses arkane practices similar to waterfall model followed in SDLC. It is no better than business folks placing their bets on initiatives, based on gut feel of a few individuals.
It need not be so. If you look at large scale picture of enterprise IT, it is a fractal. So what works for structuring changes for a single application can work for enterprise IT too. For an application change, one carries out impact analysis, based on functional and non-functional requirements to figure out the changes required. Similar approach can work for enetrprise IT too. The functional requirements coming from business and non-funcitonal requirements coming from EA group. There are two critical differences though. Firstly requirements for an application are far more crystalised than business requirements meant for enterprise IT. Secondly the understanding of single application is much more rigorous than entire landscape of enterprise IT. Any approach used to structure the IT change portfolio must bear these facts and evolve a strategy to handle it. Any investment made in this area will go long way in establishing EA credibility within organisation.
These are my thoughts about various issues faced by an enterprise architect.
Here you will find thoughts related to enterprise architecture, TOGAF, SOA, BPM, MDA, MDD, Web 2.0 etc.
Subscribe to:
Post Comments (Atom)
Saturday, November 03, 2007
EA and structuring IT change portfolio
There is no steady state for EA function, as EA has unenviable job akin to converting a propellar driven aircraft into a jet aircraft, while flying. And it does not stop there, by the time EA managed to turn into a jet aircraft, new scramjet is already available and waiting for being adopted.
To cope with this constant churn, the usage of EA frameworks is widespread. But, as I had pointed in my earlier post that results on ground are only thing appreciated by end-users. This post by Tom re-emphasised the point about operationalising the Enterprise Architecture as had this post by Sam. Operationalisation of EA is what is capable of producing the results, no matter what framework was used to structure thinking and what artefacts were built. Unfortunately after spending lot of bandwidth in think and build activities, there is little spare bandwidth available for operationlising the EA.
In a large enterprise, structuring the business IT change portfolio is a great opportunity for EA function to make sure EA is operationalised. Its where the lack of bandwidth affects the EA function. Somehow this important activity uses arkane practices similar to waterfall model followed in SDLC. It is no better than business folks placing their bets on initiatives, based on gut feel of a few individuals.
It need not be so. If you look at large scale picture of enterprise IT, it is a fractal. So what works for structuring changes for a single application can work for enterprise IT too. For an application change, one carries out impact analysis, based on functional and non-functional requirements to figure out the changes required. Similar approach can work for enetrprise IT too. The functional requirements coming from business and non-funcitonal requirements coming from EA group. There are two critical differences though. Firstly requirements for an application are far more crystalised than business requirements meant for enterprise IT. Secondly the understanding of single application is much more rigorous than entire landscape of enterprise IT. Any approach used to structure the IT change portfolio must bear these facts and evolve a strategy to handle it. Any investment made in this area will go long way in establishing EA credibility within organisation.
To cope with this constant churn, the usage of EA frameworks is widespread. But, as I had pointed in my earlier post that results on ground are only thing appreciated by end-users. This post by Tom re-emphasised the point about operationalising the Enterprise Architecture as had this post by Sam. Operationalisation of EA is what is capable of producing the results, no matter what framework was used to structure thinking and what artefacts were built. Unfortunately after spending lot of bandwidth in think and build activities, there is little spare bandwidth available for operationlising the EA.
In a large enterprise, structuring the business IT change portfolio is a great opportunity for EA function to make sure EA is operationalised. Its where the lack of bandwidth affects the EA function. Somehow this important activity uses arkane practices similar to waterfall model followed in SDLC. It is no better than business folks placing their bets on initiatives, based on gut feel of a few individuals.
It need not be so. If you look at large scale picture of enterprise IT, it is a fractal. So what works for structuring changes for a single application can work for enterprise IT too. For an application change, one carries out impact analysis, based on functional and non-functional requirements to figure out the changes required. Similar approach can work for enetrprise IT too. The functional requirements coming from business and non-funcitonal requirements coming from EA group. There are two critical differences though. Firstly requirements for an application are far more crystalised than business requirements meant for enterprise IT. Secondly the understanding of single application is much more rigorous than entire landscape of enterprise IT. Any approach used to structure the IT change portfolio must bear these facts and evolve a strategy to handle it. Any investment made in this area will go long way in establishing EA credibility within organisation.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment