CIO Dashboard » 16 Enterprise Architecture Strategies Learned The Hard Way

16 Enterprise Architecture Strategies Learned The Hard Way

post by Chris Curran on June 30, 2010

Co-authored with David Baker

We’ve been spending time thinking through the differences in implementing new or improving existing EA capabilities for smaller, say a few billion in revenue and larger firms in the Fortune 100 or thereabouts. Because the larger firms tend to have many complex, often unrelated business units, the role of centralized IT functions can also be quite complex, even unclear. Furthermore, centralized enterprise functions have many challenges in driving standards throughout diverse, geographically scattered units.

Here is our hard-earned list of strategies, observations, insights and lessons learned over a collective 55+ years of EA and IT strategy work with over 100 companies. See what you think and what you would add (or disagree with).

An exhaustive enterprise level blueprint is virtually impossible to build - it’s too big and no one will buy-in
The best strategy blends a direction-setting enterprise blueprint and business unit and domain blueprints
Centralized accountability for the EA function is a predictor of success
A centralized team of architects is critical in driving EA standards and approaches
Architects must be assigned to projects as core team members (60%+ of total EA FTEs) rather than “advisors”
EA should be measured in 2 ways: business capabilities delivered and costs of core services
Measure EA as an asset - what does it cost to provide the service and what return does the business get from the business capabilities delivered?
Architecture leadership requires strong management, business operations and technology skills, most likely in 3 different types of people; don’t expect your chief architect to run the EA function
Methods and governance must be integrated into existing work processes (eg, project approvals, SDLC) rather than a new overlay
Enterprise Architecture is not always the best name for communicating; maybe Strategy & Planning or Enterprise Transformation is better
The best large companies have “business architecture” teams reporting to the business (or dual reporting to business and IT)
Leading companies have reference architectures in place for 90% of the technical domains
Your senior enterprise architects must have the right cultural skills and awareness to integrate well with upstream business partners and downstream technical users
High performance groups maintain consistent, formalized EA involvement in the SDLC to translate blueprints into sufficiently detailed starting architectures for each project as well as accurate cost and resource estimates
Mature organizations target 40% EA resource time for strategic planning and 60% on SDLC tasks, and typically err on spending more time on SDLC tasks
Strong credibility and trust amongst Business and IT partners is a predictor of EA success. Credibility has typically been gained via joint strategic planning efforts, one project at a time.

We would love your reactions and comments. Please share your experiences!

George Tomko

Thought provoking. Going through them one-by-one, my reactions:
1) Somebody was able to build the pyramids, so it can be done. Like the recent health care bill, it would be thousands of pages and be very taxing on the organization to deliver and stick with it;
2) As long as there is coherence in the linking of the enterprise to the businesses;
3) To the extent that the accountable individual is a believer and a champion;
4) Not sure - I have seen a “COE” approach work as well. Collecting too much primo talent in one place can be difficult to maintain;
5) Totally agree;
6) I might add a measurement dimension along the lines of “core customer value propositions enabled”;
7) This is more of an “art” than science so it may not be as much about metrics as directions and trends”;
8) Agree - chief architect should not be straight jacketed into running anything;
9) Totally agree;
10) I personally prefer “Enterprise Transformation”;
11) Yes - enables buy-in;
12) Maybe. I wonder the level of “hygiene” on what these companies have in place. Sometimes they get moldy and are not kept up-to-date;
13) OK. The ultimate for me is to have credibility however manifested;
14) I would agree, provisionally. I think that so-called high-performance groups are better at such things when operating from a running vs. a standing start;
15) Sounds about right;
16) I think that these are critical success factors but not necessarily predictors. My main reason for this is that IMHO “execution” is the biggest predictor of success and solid planning and the joined hands of business and IT go along way to facilitate flawless execution through shared purpose, commitment, expertise, accountability and follow-through.

My two cents. Nice effort on pulling this list together. Thanks.
George Tomko

Thought provoking. Going through them one-by-one, my reactions:
1) Somebody was able to build the pyramids, so it can be done. Like the recent health care bill, it would be thousands of pages and be very taxing on the organization to deliver and stick with it;
2) As long as there is coherence in the linking of the enterprise to the businesses;
3) To the extent that the accountable individual is a believer and a champion;
4) Not sure - I have seen a “COE” approach work as well. Collecting too much primo talent in one place can be difficult to maintain;
5) Totally agree;
6) I might add a measurement dimension along the lines of “core customer value propositions enabled”;
7) This is more of an “art” than science so it may not be as much about metrics as directions and trends”;
8) Agree - chief architect should not be straight jacketed into running anything;
9) Totally agree;
10) I personally prefer “Enterprise Transformation”;
11) Yes - enables buy-in;
12) Maybe. I wonder the level of “hygiene” on what these companies have in place. Sometimes they get moldy and are not kept up-to-date;
13) OK. The ultimate for me is to have credibility however manifested;
14) I would agree, provisionally. I think that so-called high-performance groups are better at such things when operating from a running vs. a standing start;
15) Sounds about right;
16) I think that these are critical success factors but not necessarily predictors. My main reason for this is that IMHO “execution” is the biggest predictor of success and solid planning and the joined hands of business and IT go along way to facilitate flawless execution through shared purpose, commitment, expertise, accountability and follow-through.

My two cents. Nice effort on pulling this list together. Thanks.
Bob Deutsche

Interested most in lesson learned #6 and #7. Have you found any companies who have done a good job of demonstrating the value of EA to an enterprise in terms that a financial auditor would understand and agree with? We have used code reuse successfully for a number of years, but over time, particularly as you start moving towards some kind of a services oriented ecosystem, it seems to become just something that is expected and carry less value.

Further, as organizations start to realize that their entry into the Cloud in any kind of an industrial manner requires a somewhat robust and services based enterprise architecture, the above becomes even more important. Service interoperability in the Cloud assumes a significant level of standardization and consistency in the way the entire BDAT framework is constructed and to be honest, unless somebody has successfully tackled the EA value question as mentioned above, I am a bit concerned that Cloud potentially becomes another SOA type of experience.

Thanks,

Bob
Bob Deutsche

Interested most in lesson learned #6 and #7. Have you found any companies who have done a good job of demonstrating the value of EA to an enterprise in terms that a financial auditor would understand and agree with? We have used code reuse successfully for a number of years, but over time, particularly as you start moving towards some kind of a services oriented ecosystem, it seems to become just something that is expected and carry less value.

Further, as organizations start to realize that their entry into the Cloud in any kind of an industrial manner requires a somewhat robust and services based enterprise architecture, the above becomes even more important. Service interoperability in the Cloud assumes a significant level of standardization and consistency in the way the entire BDAT framework is constructed and to be honest, unless somebody has successfully tackled the EA value question as mentioned above, I am a bit concerned that Cloud potentially becomes another SOA type of experience.

Thanks,

Bob
Chris Curran

Thanks George and Bob.

@George: Regarding #1, I have seen it done too, but the results are not maintainable and the organization generally does not buy in cause they lost interest after the second year passed and it still wasn’t done :). Regarding #4, I think the centralized model is needed, at least to build the organizational awareness, skills and consistency in approaches, and then some of the central experts can be re-deployed.

@Bob: The EA value question has to be asked in a broader context. Does the organization plan, justify, manage and track any of its investments (other than those made by the Treasurer) at that level of rigor?

Appreciate the thoughtful reading and commenting.

-cc
Chris Curran

Thanks George and Bob.

@George: Regarding #1, I have seen it done too, but the results are not maintainable and the organization generally does not buy in cause they lost interest after the second year passed and it still wasn’t done :). Regarding #4, I think the centralized model is needed, at least to build the organizational awareness, skills and consistency in approaches, and then some of the central experts can be re-deployed.

@Bob: The EA value question has to be asked in a broader context. Does the organization plan, justify, manage and track any of its investments (other than those made by the Treasurer) at that level of rigor?

Appreciate the thoughtful reading and commenting.

-cc
Adrian Campbell

This is a good list. I have some comments though.

1. The enterprise architecture blueprint (i.e. the EA content) needs to be developed in iterations, and treated as a living document that will never be complete. Aim for each iteration to provide value in it’s own right.

2. I agree that there needs to be different aspects to the business and IS strategies that address different segments of the enterprise. They shouldn’t conflict with each other though.

3. The EA function needs an executive sponsor such as the COO that is accountable for the success of EA.

4. I agree

5. Its the Solution Architects that should be assigned to projects as core team members. Enterprise Architects will be involved from a governance, compliance and design assurance perspective in quality gates/steering group meetings, and as an advisor. There are usually not that many enterprise architects and too many projects for them to be core members of every project. Being a ‘Core’ member of a project team implies that they are managed by the project manager, whereas the relationship should be the other way around.

6. I agree that EA should be measured in terms of business capabilities delivered, but also in terms of value delivered. Cost of services is just one of many ways of measuring value.

7. EA is a core business function in the same way that Finance Management or Sales & Marketing are core business functions. We should treat the Enterprise Architecture content as a knowledge management asset. The value is the return on knowledge (ROK) that is used in supporting decision making.

8. The EA function does need strong leadership. Doesn’t always get it though. In all the EA teams I have encountered, the Chief Enterprise Architect does also run the EA function. Within a larger EA team, there are often specific managers for the Business Architecture, Information Architecture, Application Architecture, Infrastructure Architecture aspects.

9. I partially agree. Aspects of EA Governance, Compliance and Design Assurance processes should be integrated into existing Strategic Planning, Portfolio Management, Programme and Project Management, Software Development and Service Delivery processes, but the Enterprise Architecture Development process (i.e. TOGAF ADM) will be a new overlay.

10. The name â€˜Enterprise Architectureâ€™ is all too easily confused with â€˜Solution Architectureâ€™, â€˜IT Architectureâ€™ which is a source of confusion so there are often suggestions for new names for â€˜realâ€™ Enterprise Architecture. Iâ€™ve not yet found a new name I like though it is becoming common to include Enterprise Architecture within a Strategic Change Management team.

11. Business Architecture is just one of the domains of Enterprise Architecture. All of Enterprise Architecture should be reporting to the business (i.e. the COO) rather than to IT (i.e. the CIO).

12. A Reference Architecture is a key component of the target Enterprise Architecture as a whole. In some cases these are provided by industry reference architectures.

13. I agree in general although Iâ€™d say that Enterprise Architects probably need to be much more business focused than IT focused. IT is often seen as part of the â€˜problemâ€™ and EA needs to be in alignment with the business.

14. This is more the responsibility of the Solution Architects who need to liaise with the Enterprise Architects to translate the Enterprise Building blocks into Solution Building Blocks. The Solution Architects should ideally form part of a â€˜virtualâ€™ EA team.

15. The 40% EA resource time on strategic planning and 60% on SDLC tasks mainly reflects the current overemphasis on IT Architecture being done by Enterprise Architects. I think the ideal percentages should be the other way around i.e. 60% strategic planning and 40% project related work.

16. I agree that the credibility of the Enterprise Architects and their trust relationships is critical. Building that credibility and trust starts with working closely with the business on strategic change programmes.
Adrian Campbell

This is a good list. I have some comments though.

1. The enterprise architecture blueprint (i.e. the EA content) needs to be developed in iterations, and treated as a living document that will never be complete. Aim for each iteration to provide value in it’s own right.

2. I agree that there needs to be different aspects to the business and IS strategies that address different segments of the enterprise. They shouldn’t conflict with each other though.

3. The EA function needs an executive sponsor such as the COO that is accountable for the success of EA.

4. I agree

5. Its the Solution Architects that should be assigned to projects as core team members. Enterprise Architects will be involved from a governance, compliance and design assurance perspective in quality gates/steering group meetings, and as an advisor. There are usually not that many enterprise architects and too many projects for them to be core members of every project. Being a ‘Core’ member of a project team implies that they are managed by the project manager, whereas the relationship should be the other way around.

6. I agree that EA should be measured in terms of business capabilities delivered, but also in terms of value delivered. Cost of services is just one of many ways of measuring value.

7. EA is a core business function in the same way that Finance Management or Sales & Marketing are core business functions. We should treat the Enterprise Architecture content as a knowledge management asset. The value is the return on knowledge (ROK) that is used in supporting decision making.

8. The EA function does need strong leadership. Doesn’t always get it though. In all the EA teams I have encountered, the Chief Enterprise Architect does also run the EA function. Within a larger EA team, there are often specific managers for the Business Architecture, Information Architecture, Application Architecture, Infrastructure Architecture aspects.

9. I partially agree. Aspects of EA Governance, Compliance and Design Assurance processes should be integrated into existing Strategic Planning, Portfolio Management, Programme and Project Management, Software Development and Service Delivery processes, but the Enterprise Architecture Development process (i.e. TOGAF ADM) will be a new overlay.

10. The name â€˜Enterprise Architectureâ€™ is all too easily confused with â€˜Solution Architectureâ€™, â€˜IT Architectureâ€™ which is a source of confusion so there are often suggestions for new names for â€˜realâ€™ Enterprise Architecture. Iâ€™ve not yet found a new name I like though it is becoming common to include Enterprise Architecture within a Strategic Change Management team.

11. Business Architecture is just one of the domains of Enterprise Architecture. All of Enterprise Architecture should be reporting to the business (i.e. the COO) rather than to IT (i.e. the CIO).

12. A Reference Architecture is a key component of the target Enterprise Architecture as a whole. In some cases these are provided by industry reference architectures.

13. I agree in general although Iâ€™d say that Enterprise Architects probably need to be much more business focused than IT focused. IT is often seen as part of the â€˜problemâ€™ and EA needs to be in alignment with the business.

14. This is more the responsibility of the Solution Architects who need to liaise with the Enterprise Architects to translate the Enterprise Building blocks into Solution Building Blocks. The Solution Architects should ideally form part of a â€˜virtualâ€™ EA team.

15. The 40% EA resource time on strategic planning and 60% on SDLC tasks mainly reflects the current overemphasis on IT Architecture being done by Enterprise Architects. I think the ideal percentages should be the other way around i.e. 60% strategic planning and 40% project related work.

16. I agree that the credibility of the Enterprise Architects and their trust relationships is critical. Building that credibility and trust starts with working closely with the business on strategic change programmes.
Pingback: Tweets that mention BusArch #News Enterprise Architecture Strategies From Large Companies â€” CIO ...: Tagged as: Architecture, busines... -- Topsy.com()
Chris Lockhart

Personally I find #3 to be one of the most critical. You can measure all you want but without a focal point of accountability, responsibility and promotion, it will all be for naught.
Chris Lockhart

Personally I find #3 to be one of the most critical. You can measure all you want but without a focal point of accountability, responsibility and promotion, it will all be for naught.
Lance Beam

Chris and David, thanks enjoyed the read. “7. Measure EA as an asset â€“ what does it cost to provide the service and what return does the business get from the business capabilities delivered?” reflects an interesting mindset which places the burden of proof on EA. This was definitely the case my organisation when the EA practice was first being established. A more interesting question now that the EA discipline is up and running is “what does it cost the organisation when EA is not involved?”

Keep em coming!
Lance Beam

Chris and David, thanks enjoyed the read. “7. Measure EA as an asset â€“ what does it cost to provide the service and what return does the business get from the business capabilities delivered?” reflects an interesting mindset which places the burden of proof on EA. This was definitely the case my organisation when the EA practice was first being established. A more interesting question now that the EA discipline is up and running is “what does it cost the organisation when EA is not involved?”

Keep em coming!
Graham Johnson

Chris

I am interested in your point 13:

“Your senior enterprise architects must have the right cultural skills and awareness to integrate well with upstream business partners and downstream technical users.”

What cultural skills and awareness did your have in mind?
John Gannon

I only recently came across this article. I am a Sr. Program Manager supporting a large intelligence agency with their enterprise. I manage their Development and Test Lab to help streamline the development cycle against established operational policies and procedures, assist with implementing virtualization at the very beginning of the development cycle and perform test procedures that are accepted across the intelligence community. The operational enterprise is rather large and supports a diverse set of customers. Very recently, some of the senior managers have begun to question the relevance of a development lab. When I first heard of these questions, I literally could not believe my ears. The fact that these folks are in charge of an enterprise and question the value of a development lab and how it may affect their operational enterprise floored me. I’m in the beginning stages of creating a white paper explaining the reasons behind establishing and supporting a robust development/test lab. Many of the points raised in the article above are exactly what I am planning to discuss. One issue I see that will require a lot of work on my part is convincing folks whose only concern is how a budget is spent versus attempting to prove a negative, that a development lab will help significantly minimize problems within the operational enterprise.

All feedback I’ve received from senior EAs and SEs is that my client must literally be out of their minds to even consider NOT having a development/test lab for their enterprise. Have any of you out there had to show the value of a development/test lab to a client? I have been comparing the cost to the cost of Disaster Recovery, mostly in the sense that as long as you never have to use your DR plan, it appears that the funds for DR are wasted. However, the ONE time you do need it, you will be thankful that you made the investment.

In any case, thanks for the article and the points you bring to the discussion.
Pingback: Digital Keystone Skills - IT Skills for the Digital Age — CIO Dashboard()