Lately, I have been wondering in my dealings with clients, prospects and online forums if we have forgotten this most basic, but important goal of EA – adaptability – the ability to accommodate change quickly and easily. Complexity and the rate of change continue to increase, but the focus of many EA groups seems to be more focused on accommodating particular focus areas – major projects or business areas. While much of this is because we are in a more tactical arc of the pendulum swing right now due to the economy and resource constraints, it is important to maintain a focus on enabling change while we work on specific domains or initiatives at the sub-enterprise level.
There are two elements that are crucial to an organization creating and maintaining an adaptive environment – standards and governance. Standards provide a common place to start – whether they be infrastructure standards like standard vendors and products for hardware and middleware; or application standards like coding standards, common integration practices or reusable components; or data standards like common metadata, naming standards and authoritative sources. But in addition to defining these standards, effective governance must be in place to ensure that the standards are applied, especially in times such as these where there is immense pressure on project teams to deliver value and results as quickly as possible. It is actually times like these that demand EA and governance to be most effective – when there seems to be an organizational push to eliminate anything that might delay project delivery. This is when EA, IT and enterprise leadership must continue to place adaptability as a primary goal for planning, design and implementation.
I have some other ideas on this area as well, so see my other post this month for more.
As organizations continue to struggle with the complexity and amount of change to deal with, the EA team plays a crucial role in laying a foundation of adaptability for the organization to build from. Once an organizations has done an acceptable job of providing a standardized infrastructure and at least basic governance of infrastructure standards, focus tends to shift towards the application portfolio and integration approaches. This is natural and seems to conform to most of the evolutionary models of EA, such as the one from MIT Sloane CISR in Enterprise Architecture as Strategy. However, I would like to provide you with an alternative to consider as I see organizations continually struggle with business units demanding more uniqueness to the functional systems they need to run their part of the business.
I think the key for some organizations to achieve a more adaptive environment is to focus on architecting the information and integration environments. If information was more standard and consistent BETWEEN information systems with a common integration architecture (standard methods, components, messages, and middleware), then the information systems themselves could be unique functionally. The architecture would need to provide the means of translating information formats and content from systems into the standard format and content for sharing outside the system. This would also support SOA approaches, cloud computing strategies, mobility, and other approaches being pursued today.
As an EA team, are you focusing on the functionality of a specific area or are you leaving that to the project team, so that you can focus on the shared aspects of an application environment, namely the information assets and integration capability across the enterprise?
Last month, in the Who Decides? entry and in a longer FAQ article, I discussed the pros and cons of various governance models for formalizing EA standards. In particular, I made the point that the EA team should neither take it upon itself to be the final decision-making body to approve standards, nor to let it default to them. If they do, they may find themselves in an awkward situation, defending individual standards after the fact, or even defending having standards at all. It is important that approval rests at a high enough level that the decision will be viewed as legitimate by the broadest possible stakeholder community.
In that article I opened a polling question asking “What is the highest level in your organization involved in any part of formally approving EA standards?”. That poll remains open for another month, but in the meantime the preliminary results reveal one positive outcome while also pointing to an opportunity for improvement. The positive outcome is that only 8% indicated that the EA team itself made the standards decisions. Less promising is that 17% replied that nobody formally approves standards and “Other IT management” made up another 8%. So, combined, 33% of respondents have standards without higher-level leadership support. The better news is that 59% indicated that their CIO or the CIO’s direct reports were responsible for authorizing standards. At least in those cases the IT organization is operating with some level of implied unity and authority.
As you might have surmised by doing the math, only 8% had anyone from the business involved in the governance process. This result is likely an indication that the respondents EA programs operate mainly in the technology space. Few such programs are able to attract business leadership to the governance process. This is the area that EA leaders should work to improve, and we expect it will happen as our discipline demonstrates increased maturity in information and business architecture. Business leadership will have a more direct line of sight to the implications of EA standards (which will, by definition, be more holistic and not just technology based), and will be more inclined to take an active role in EA decisions that affect them.
This leads me to our new poll. The flip side of standards approval is standards compliance. The true test of how well standards guide and inform the organization can be measured, in part, by how well they stand up against challenges. So, we’re curious about our readers experiences and will report out on this new poll in a future posting.
Do you sometimes feel that your EA standards don’t carry any weight? You create them, publish them, and then when it comes time to apply them you find yourself re-justifying the standard or even justifying the need for standards in the first place? Even commonly accepted de facto standards with long histories in an organization can fall prey and need to be re-justified before each use.
It’s a very common story and it points to a fundamental weakness in EA governance. Compliance processes and design reviews alone aren’t the answer – they can often lead to accusations that you are acting like the “EA police”. An organization needs a robust EA approval process as well.
Most organizations, regardless of maturity and for a variety of reasons, need to address/re-address the question of “who decides?” when it comes to standards, roadmaps and the overall EA strategic direction. The key to success is that some degree of meaningful standards must be decided in advance of the need to actually apply them. Enterprise Architects, though, SHOULDN’T be the ones to decide (or enforce) standards. Why not, and if not, who should?
Independent EA authority may work for the least controversial EA decisions, but it usually won’t stand up for the big ones or when more powerful or influential leaders choose to go a different way. The root of decision-making authority for EA rests with the body that makes policy and investment decisions for the organization.
Is that practical, or even plausible? It is if implemented in a model that relies on layers of decision-making authority, with delegation pushed downward, while accountability is maintained upward to that ultimate root authority.
We’re gathering data on the level of governance involved in EA standard approval across our readers. Please take a moment to answer the attached polling question, and read more on this topic on our website. We’ll let you know how people respond in a future blog entry.
Recently I saw a question posted on a popular EA forum, asking about detecting the “architecture readiness” of the poster’s organization. That got me to thinking about what we mean about “readiness” and is it that relevant anymore. I admit that in the mid-90′s we would discuss the notion of an organizations readiness to embrace EA, but my perspective has changed drastically. I think that the question is no longer “Is my organization ready to embrace and support EA?” but rather “How can I be effective in utilizing an EA approach in my organization?” Clearly, the issues demanding EA support are still prevalent and the maturity of EA as a discipline has increased during the time since the mid-90′s.
I do not believe that any EA function can be diagnosed quickly, as most of the issues regarding “readiness” are probably a unique combination within a company. It starts with identifying the leverageable strengths, obstacles to overcome, and methods of mitigating those obstacles – including awareness at the executive level. I don’t believe that any organization is completely “unready” for EA, but there are certain factors that are a quick read into how long it will take for EA to be a valuable, recognized formal method of helping the organization plan, rather than just a glorified design standards group. Key among those factors is the understanding of and desire for EA as a strategic planning discipline by the CIO first, and the rest of EA management, second. Many times, it helps to build some of the context level artifacts BEFORE you attempt to build executive awareness as those artifacts can be a very powerful part of the argument. There are other activities (communication, collaboration, process integration, separating and defining roles and responsibilities among different architecture levels, and governance to name the most important) that all work together to establish a culture of EA – which is really what we are talking about here.
The question for public sector organizations is no longer “Should we?” Now it is “What is the Best Way …?
E-government, the web-based online delivery of government services to its constituents, is the norm at all levels – federal, provincial/state, county and municipal – in developed countries. In developing countries, it is even becoming more achievable. But is this just for external services?
I am pleased to have been invited to join Ronald Ross, Roger Burlton and many other noted speakers to present at this year’s Business Rules Forum at the Bellagio Hotel in Las Vegas. I will be presenting on Monday, November 2 during the all-day Business Alignment Symposium and also participating in a panel discussion with the rest of the Symposium faculty at the end of the day.
Use Special Code 9SPGP when you REGISTER to receive a 10% discount!
Title: “Enterprise Alignment through Enterprise Architecture and Governance”
Achieving ambitious, large scale enterprise transformation demands unique competencies and perspectives, different from those required for day-to-day project execution and operations. It requires an enterprise view of alignment, bridging big-picture strategy consistently into hundreds of smaller scale implementation and operational decisions. Enterprise Architecture (EA) and effective Governance are two of those critical competencies. This session will explore the techniques and approaches that leading organizations use to institutionalize these core management disciplines, reaching beyond the IT department to create a true partnership with business leadership.
How to sort out competing Business, IT and EA priorities
Perspectives: Strategic vs. Tactical, Enterprise vs. Project, Process vs. Content
The Enterprise View – Capabilities, Portfolios and Roadmaps
Alignment deliverables for the executive and models for EA consumer
The human challenge – Culture, People, Persuasion, Roles, Responsibilities
We have a lot of work to do on our relationships! Fully 71% responded that the relationship doesn’t exist or that there is room for improvement. There is some good news though – 57% at least HAVE some sort of relationship that needs improving and 29% consider the state of their relationship to be “healthy”.
Here is an excerpt from an offline comment that I found particularly relevent and insightful:
“I’d say you are spot on with your observations and I think you need to let both groups know that an enterprise architect is fundamentally a differently-skilled person than a project manager. As you point out, an EA is concerned with the future, the long-term strategy and the big picture. A project manager is concerned with the here-and-now, budgets, resources, details and “the little picture”. An EA must be aware of all projects in the organization, and makes decisions regarding how one project can easily affect another – and maybe not in a good way. Project managers are under huge pressure to manage the scope to the budget and the timelines, while EAs are not.
My point is that an EA thinks dramatically different than a PM. Both the EA and the PM need to understand and recognize this and build on the differences and not let those differences destroy the relationship, and certainly to not jeopardize either a project’s goals nor the enterprise IT strategy.”
Well said. The writer asked to let both groups know; consider it done!
Thanks to all again that had interest in this topic. Comments are open if you have any additional ideas.
A few months back, at the recent EA Symposium in Toronto, I gave a presentation on the tensions that exist between project staff, particularly project managers, and the EA Team. The audience was primarily of the architect persuasion. The session was well received in spite of the fact that I was fairly tough on them, challenging them to take responsibility to make sure their relationships with their project communities were healthy and productive. The core message of the session, as well as the overall conference, was about balance – how to live up to the larger role of an enterprise architect in addressing holistic, enterprise-wide, strategic opportunities while also ensuring that today’s challenges and initiatives are supported through their work.
I touched on future state EA content creation, governance, and their coach/assist role. The latter requires rolling up their sleeves and engaging directly with project teams. Recommendations included warnings to not reside in an ivory tower, and advice to actively engage with project and asset communities, to encourage contribution, to communicate and be transparent in their work, and to not act as the architecture police. While these messages aren’t a surprise to those of you who have worked with us, the audience seemed to appreciate hearing them, resulting in 40 minutes of group discussion.
What I enjoyed the most about this discussion was the enthusiasm of the audience. As a fairly typical conference audience, the group was very diverse in experience, representing private and public sectors, large and small organizations, and veterans of EA work (both successful and wounded) plus newbies and wanna-be’s. Many described themselves as being in situations not of their making – stuck being reactive vs. proactive, no time to look forward because they were full time project engineering support resources, they felt they did solid forward-looking strategy but nobody cared, project needs always trumped longer-term objectives, no leadership support, etc. The better news is that, after some discussion, most saw that applying the techniques we discussed could help them be more balanced, improve their situations, and earn the right to be more influential and better leaders.
Coming full circle to the main topic, at the end of the discussion I held an informal poll to find out how many of them thought the relationship between their EA group and their project counterparts was “healthy” vs. “room for improvement” vs. “non-existent”. Despite the fact that the diversity of the audience makes it impossible to draw any statistical conclusion from their answers, and that each likely interpreted the choices differently, the responses were overwhelmingly “healthy” and “room for improvement” with almost no “non-existent”. So for this group, they generally thought they are doing ”OK”.
Being a scientist and an analyst by nature and training, I wanted to get an alternative perspective so I sought to gather data in a different venue. A few weeks ago I presented at the Project World conference in Baltimore, and chose to do a round-table discussion on the same topic. My audience at that occasion was completely different, primarily project managers and business analysts. Not surprisingly, it was a very different discussion. Once we level-set on roles and responsibilities of architecture and the varations from organization to organization it turned into a good discussion. I believe I left them better informed about the nature of the relationship between themselves and the EA community.
At the conclusion, I asked them the same question I asked the EA Symposium audience. Not surprisingly, I got the opposite result. They skewed heavily to the “room for improvement” and “non-existent” side when describing the relationship. The good news is that they admitted that it wasn’t entirely the fault of their EA teams, and as much a result of the pressures they were under to ”eliminate distractions and just get their project done”. Most suggested that they now had a better appreciation for the role of EA and would be more open to listening upon their return. The bad news was that they also said that their EA groups had to do a better job communicating and engaging as well.
So, my advice to the Enterprise Architects out there: Even if you think you are doing well managing the relationship with your project community, you are probably not doing as well as you think you are, at least from their perspective. Take some steps to health-test that relationship, either formally or informally, and put an improvement plan in place. Give us a call – we can help.
Finally, to feed my scientific need for more data, please reply to this thoroughly un-scientific poll. If I get any meaningful data and reach any conclusions, I will let you know in a future post.
Posted by Tim Westbrock 
