If you don’t know the answer to this, how can you expect others to understand EA?
This is a simple question, but we are looking for comments from your readers to help others (without their answer) come up with the answer that meets their situation. While everyone probably has a unique approach to the process, organization, and deliverables for EA; we find that the objectives of EA are similar across organizations. You may not currently be fulfilling the reason why you are doing EA, but you have to at least know what you are TRYING to do.
Let us know by your comments, Why are you doing enterprise architecture?
If an enterprise architecture team tries to be everything to everybody, at all possible levels of detail, at every point in time, it will fail. The result will be that it doesn’t do anything for anybody, which would be unfortunate. When it works, EA can have a significant impact on the quality, consistency, and speed of decision-making.
How can you avoid the inevitable overload and the misunderstood expectations? Every great enterprise architecture team I know constantly examines the work it is doing in the context of the resources it has available, the number of hours available each day, the objectives it must meet and the expectations of its stakeholders. In addition, the leaders appreciate that EA teams evolve over time and adjust to the changing needs of their business. The key is to know which activities they must perform, how many at a time, how frequently and in what order. The attached presentation is a starting point to understand the range of activities you COULD do. The challenge is to determine which of these you CAN and SHOULD do.
As the annual corporate budgeting season begins, we find ourselves again fielding client inquiries about the role that EA should play in this annual rite. Like many such EA best practice questions, there is the EA purist answer and then there are the many variations of more practical answers.
In an ideal world, enterprise architecture should have little to do directly with the annual budgeting process, per se, but instead be feeding the portfolio planning process. We “inform” that process, which should be complete before the budgeting process begins. The analysis of strategy and business capabilities enables the creation of a holistic enterprise architecture future state, and the comparison to current state charts a forward-looking roadmap and transition strategies. That work provides the list of potential major investments, supplementing the list of projects that is the typical starting point for the investment process. The budgeting process systematically transforms that list of “potential” investments into those that can be achieved in the next planning cycle based on available funds, resources, risks and business priorities. EA’s role is to impartially analyze the list of potential investments and guide the organization through the implications of various scenarios.
From a practical standpoint the reality is rarely that straightforward. For example, there often isn’t a portfolio planning process distinct from the budgeting process. What the organization can afford, therefore, is a dominant constraint before strategic or even tactical outcome can be thoroughly analyzed. The EA team must never be arm’s-length if our mission is to impact the choice of projects and guide the evolution toward the desired future state.
Another reality is that, in many organizations, the future state is rarely well-formed. As such, most EA teams must leverage the opportunities provided by projects already on the list. Being active in the budgeting process is a fail-safe to learn about business opportunities they might not have seen, to gain new insights into the priorities of the organization, and to discover paths that will help bring potential future states into focus.
There are other answers to the EA role in budgeting question as well, not the least of which is dealing with management expectations. How far enterprise architects should engage, and at what level, is situational and we’d be happy to discuss offline with anyone that is interested.
Remember, EA should not be constrained by the list of funded projects but should focus on reconciling long and short-term interests. We should never confuse or stifle the “out of the box” thinking that EA should provide with the realities of short-term investment and implementation decisions. EA involvement in the budgeting process is probably too late in the overall investment decision-making continuum, but it can be a good place for the EA team to ask the questions that would demonstrate the need for more proactive and broader planning in the future.
Check out my presentation below. Let me know what you think.
Directions: As with any domain of EA (business, info/data, application, technology), you must establish a view, value proposition, and advocate/sponsor to apply architecture at the enterprise level. Without that, you continue the cycle of silo-oriented decision-making, design, and solutions.
OK, so you think you are practicing Enterprise Architecture, right? As I have pointed out before, the key is the answer to the question, “Are you architecting the enterprise, or are you architecting IT?”
As I dare say, most of you (if not all) would answer honestly that you are architecting the IT environment (apps, data and infrastructure), albeit with a significant alignment with the business of your enterprise. In any case, as I have been having this conversation with audiences, practitioners and clients over the last couple years (or even longer as a client of mine pointed out yesterday – Thanks, Marc!), I have been suggesting that true EA requires business-owned Enterprise Business Architecture (EBA) and Enterprise Information Architecture (EIA).
The implication of this suggestion is that the EBA thought of in the traditional sense is not within the domain of IT; but rather owned, driven and primarily developed and maintained by a group of business professionals within the enterprise. Further, there is also a separation of EIA and Enterprise Data Architecture, with the former under business direction and the latter under IT direction, joining EA efforts for application and technology. Figure 1 depicts the relationships described above.
There is a role for IT EA professionals to play. As the figure suggests, a relationship exists between the business domain and IT domain. Initially, the IT architects must translate the impact of the business and information domain upon the architectures within the IT domain. This is done primarily through modeling and capabilities analysis, a topic for another time. IT professionals have the modeling experience, plus a vested interest in the outcome of the business and information architecture efforts, to be valuable members of the team working on the business domain architectures.
Recently, I have been working with an organization going through a significant transformation and they decided to do exactly what I have been suggesting. A group of business representatives including IT representation, lead by a representative of the executive leadership team, has taken ownership of business and information architecture to define how the business will transform. It will then become the IT Chief Architects responsibility to lay that business blueprint on the IT landscape to translate the changes necessary within IT to support the business transformation.
Just recently I learned that a client’s CIO leadership team began a detailed and substantive discussion on EA principles, the implications they carry for their organization, and how they can use them to transform their journey into the future. I don’t see this as often as I’d like. While gaining that level of leadership engagement in the creation and use of EA principles has long been a desired outcome, it is still somewhat rare. In this case, it was a combination of good luck, good timing, and a skilled Chief Architect who was able to keep principles visible and to broker the discussion with leadership. There is a lesson to be learned here.
With common sense as a significant part of a good set of EA principles, it is easy for a leadership team to write them off as “a statement of the obvious” and not pay much attention. As enterprise architects, our goal must be to make principles relevant. The approach is for us to demonstrate how they are used in practice and to show that they are more than a collection of catchy phrases.
For each principle individually, and for the set as a whole, it is important to be able to explain them in real-world terms. This means choosing principles that guide desired behaviors and explain their rationale and implications in a form that leaders can relate to, with an emphasis on how they affect decision-making at all levels.
Unfortunately, I see many examples of principles that don’t gain traction. When that happens, EA principles have little value. When I diagnose the situation I often see that a lot of energy was consumed in creating the perfect written words, with less energy committed to bringing the principles to life.
A few tips: Always be sure to include rationale and implications, but don’t worry so much about making them perfect, just strive to make them good enough. Invest the extra energy in bringing them to life in four ways:
Ensure that ALL members of the core and extended EA teams understand what the principles really mean and how they are used
Be sure to actively and visibly reference the principles in the process of creating future state EA content
Refer to the principles and use them as a test in ALL solution architecture and coaching work
Carry the principles with you in discussions with leadership at every opportunity
By using the principles every day, their value will eventually be self-evident and leadership teams will recognize them as a helpful tool in their management arsenal.
Enterprise architects have historically struggled with the process of publishing content to the stakeholders in their organization. Conventional advice has been to create an intranet site or other document repository primarily serving static documents such as strategy papers, standards lists, domain architecture documents, models, etc. That approach has its weaknesses, not the least of which is that the content and access methods aren’t particularly engaging to the larger community of casual stakeholders including members of the extended EA community of subject matter experts and contributors, and the more formal members including senior managers and leaders in both IT and the business.
Many organizations have begun to deploy blogs, wikis and other related social networking technologies in response to demand from various user communities for easy to use tools that support collaboration and information sharing. In fact, many EA practitioners are well down the road choosing social networking technologies and helping the business develop usage guidelines.
Surprisingly, EA practitioners as a whole have been reluctant to embrace the use of social networking for their own purposes, namely to share their thoughts and ideas with others in the enterprise, and to welcome commentary and perspectives from interested parties outside their own groups. The key is to become comfortable sharing trends, ideas about the impact of those trends and thoughts on future EA changes, even before fully formed. Post often and openly, resist the urge to assign rigorous categories, and tag and link freely.
The technology, and the behavioral changes that can result once the team becomes comfortable with it, can help improve the perception of the role of the EA group by the rest of the organization. It can further recruit additional participants, effectively multiplying the reach of constrained EA resources.
We have made our position pretty clear on this topic, but just to make sure everyone caught it - We think that 2010 marks the year that Enterprise Business Architecture has finally become a legitimate concern for a singnificant number of organizations, probably more than a quarter of organizations practicing EA.
To further clarify some of our thoughts, George and I sat down and recorded this webinar.
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?
Posted by Tim Westbrock 
Transformational View of EA
July 5, 2010OK, so you think you are practicing Enterprise Architecture, right? As I have pointed out before, the key is the answer to the question, “Are you architecting the enterprise, or are you architecting IT?”
As I dare say, most of you (if not all) would answer honestly that you are architecting the IT environment (apps, data and infrastructure), albeit with a significant alignment with the business of your enterprise. In any case, as I have been having this conversation with audiences, practitioners and clients over the last couple years (or even longer as a client of mine pointed out yesterday – Thanks, Marc!), I have been suggesting that true EA requires business-owned Enterprise Business Architecture (EBA) and Enterprise Information Architecture (EIA).
The implication of this suggestion is that the EBA thought of in the traditional sense is not within the domain of IT; but rather owned, driven and primarily developed and maintained by a group of business professionals within the enterprise. Further, there is also a separation of EIA and Enterprise Data Architecture, with the former under business direction and the latter under IT direction, joining EA efforts for application and technology. Figure 1 depicts the relationships described above.
There is a role for IT EA professionals to play. As the figure suggests, a relationship exists between the business domain and IT domain. Initially, the IT architects must translate the impact of the business and information domain upon the architectures within the IT domain. This is done primarily through modeling and capabilities analysis, a topic for another time. IT professionals have the modeling experience, plus a vested interest in the outcome of the business and information architecture efforts, to be valuable members of the team working on the business domain architectures.
Recently, I have been working with an organization going through a significant transformation and they decided to do exactly what I have been suggesting. A group of business representatives including IT representation, lead by a representative of the executive leadership team, has taken ownership of business and information architecture to define how the business will transform. It will then become the IT Chief Architects responsibility to lay that business blueprint on the IT landscape to translate the changes necessary within IT to support the business transformation.
Let’s hope this is the beginning of a trend.