Many enterprise architecture (EA) teams struggle with creating a program that demonstrates the level of strategic value that they believe EA should have. Taking actionable steps to remove many of the most common roadblocks to growing the strategic nature of your EA program takes time. Individual architects need to be trained and stakeholders need to adapt to new ways of thinking. Colleagues inside IT need to adjust to changes in governance and processes. Nothing happens quickly. Success will occur in fits and starts. It is important not to attempt to insert EA into every possible process all at once. It should go without saying that attempting to make too many changes at the same time will lead to certain failure. Your ability to absorb change will depend on the size of the EA program, the number of well-trained architects, and the amount of buy-in you have from senior executives to implement change.

For most programs beginning the journey to strategic engagement, I strongly recommend dividing up the enterprise into business segments and applying EA to one (or at most two) segment(s) at a time. Note that the concept of segments is poorly described but commonly used. TOGAF 9.1, Chapter 20, describes segments as being at the program or portfolio level, without describing where the boundaries of a program or portfolio should be. Chapter 40 of TOGAF 9.1 also describes a concept of architectural partition that appears to use the same concept applied to the repository itself, and not the enterprise. The concept is solid: to break down the wide span of an enterprise into manageable chunks. For this discussion, I’ll use the term segments in describing this concept.

I’m often asked how to divide up an enterprise into segments, an activity sometimes described as everything from management science to black art. The truth, as always, is somewhere in between. TOGAF provides rather vague guidance on creating both segments (by program and portfolio) and partitions (by subject area, time, maturity, or depth). Neither bit of advice offers a clear guideline to create relatively nonoverlapping architectural results. This is especially important when you have many team members working in parallel. My preference is to use value streams as the basis for dividing up the work efforts among team members.

A value stream is an end-to-end collection of activities that creates a result for a customer. Typically broken into stages, a value stream describes how (and where) value is created for one particular type of customer and product. As a result, value streams typically focus on channels, products, or customer segments. Section 2.4 of the Business Architecture Body of Knowledge (BIZBOK) is devoted to value streams and value mapping.

Using value streams in this way may seem needlessly complex. After all, why not just use organizational functions like purchasing or sales? The reason has to do with the enterprise-wide view of EA. Functional units will naturally support the silos that typically bedevil and complicate the information and technology systems of a company. Value streams cut across the enterprise, often with clear business ownership. In that manner, it’s a useful alternative that encourages enterprise thinking. In addition, value streams are often aligned with specific customer segments. By breaking the EA effort into value streams, you end up making customer experience a key element of your architectural models and processes. By segmenting the enterprise on the basis of value stream, you are working toward a future where your EA program naturally supports customer-driven requirements.

For supporting functions of the business such as HR, legal, finance, real estate, and IT, value stream mapping has to take a decidedly “internal” approach. Even with that caveat, value streams may not be a good way to create segments for supporting functions. It is often useful instead to create one or sometimes two “support” segments. Each segment would support more than one supporting business function.

Growing the function of EA one segment at a time is a well-proven method for growing the reach, impact, and importance of the EA function. Architec­tural partitioning evolved out of two influences: the first being the notion of decoupling, or segmented iteration, in systems design. The second major influence that led to the notion of partitioning was the development of the FEAF, which tackled the world’s largest EA effort — the US federal government’s enterprise architecture utilizing the Federal Segment Architecture Method (FSAM). While these origins were humble (and criticism of the way that the government implemented segment architecture was widely shared), the core concept of developing architecture in segments as a mechanism to manage both complexity and delivery has grown.

While it is easy to see the value of performing architecture in bite-sized pieces, it may not be obvious which piece to perform first. The order of attack is best based on who the stakeholders are for each segment. Some stakeholders will be more amenable to the ideas of business architecture and EA governance than others. Start with the most willing stakeholders, to gain experience and iron out the wrinkles in your processes. Then take on a stakeholder that is both willing and very visible. Success in a highly visible area will give you momentum toward adoption into other areas. Make sure, when you begin the EA adoption process in an enterprise segment that you set expectations with the business leader(s) about the efforts you will undertake, the value you hope to provide, and your hope that, upon completion, they will help you convince others in the organization to take a chance on EA.

Realize that a business stakeholder who was a successful partner at one point may become a less enthusiastic supporter at a later date. This is especially true when changes occur in leadership, since your business stakeholder may be assigned entirely new priorities and objectives. Be prepared to create altogether new relationships each time there is a change in senior leadership, even if your stakeholders themselves haven’t changed. (I cannot emphasize this enough: alliances change.)

This incremental approach provides some key benefits:

• Each EA practice finds its own set of successful contributions to be made. What succeeds in one organization may not be useful in another, so advice from outside consultants is only moderately helpful (including this Advisor). By adopting one or two segments at a time, you provide the ability for team leaders to learn what works in your organization and what doesn’t. Essentially, you are giving your EA program room to learn.

• A common mistake is for architects to “get going and go dark.” An EA team will start mapping and collecting data and produc­ing models without sharing any of that detail with stakeholders until everything is complete. The resulting architectural models are often a surprise to the organization and may end up being set aside. In addition to not being accepted, the organizational strategy itself may have changed while the architects were busy, so the resulting recommendations are not valuable. By working on one segment at a time, it is easier to set up review sessions with stakeholders every two to four weeks to secure buy-in and feedback.

• Another common mistake is to get too ambitious. If an EA program attempts to “drain the ocean” with a set of deliverables that are too comprehensive, too deeply technical, or too broad in scope to be accepted or useful, that program will quickly be sidelined. By focusing on one segment at a time, the EA program limits the risk of spreading itself too thin.

• A steady growth for EA gives you time to plan your staffing levels, hire appropriate talent, and make sure that your training plan is providing consistency and scalability.

The pitfalls that stymie an EA program are discussed in some detail in Martin van den Berg and Marlies van Steenbergen’s book Building an Enterprise Architecture Practice. They recommend creating architectural artifacts only if they can be tied to a strategic need, literally starting with the strategic initiatives and limiting effort to models that support those initiatives. That is useful advice for any EA program. Within each segment, the models you develop and the information you collect will vary depending on the needs of that part of the organization. Start with the impacts of high-level strategy on the business of that segment. Develop only the models and information you need to answer questions and accelerate the execution of those impacts. By limiting your effort within a segment to developing architecture that supports a strategy, you increase the likelihood that the models will be useful, adopted, and impactful.

Incremental growth of the EA program is simple to plan on paper, but it never happens according to plan. First off, team leaders need to be aware of the skills of EA team members. As the scope of EA grows, the strengths and weaknesses of each architect will become more and more obvious, and impactful. The most important skills are not technical, analytical, or modeling skills. The most important are consulting skills: situational awareness, inter­personal collaboration, negotiation, salesmanship, excellent written and verbal communication skills, and project management. If any architects are lacking in consulting skills, they cannot take on the support for a segment by themselves. This can greatly impact your ability to scale the program.

Each segment that gets added to your EA program scope will need con­siderable attention in the initial months after it is added. For example, if you have a business segment responsible for US $50-$100 million in revenue, the EA team can take six to nine months to perform an initial process and capability analysis and load data into a repository. Therefore, when a segment is added to the EA program, it should get a dedicated business architect and one or two dedicated IT architects until the initial architecture activities are completed. After that point, the demands from that segment will drop markedly. Knowing this will help you to plan your capacity for adding segments to your scope.

One key challenge that arises when you build your EA practice incrementally is how to incrementally add to the EA models themselves. There are two chief approaches to this. One is to create initial models in the first segment, and then add to them in each subsequent segment. The other is to approach each segment as a blank slate and then, after completing the first draft of the architecture work, merge the segment model with a growing enterprise model. The first approach minimizes rework as you move from one segment to another. The second allows each segment to see themselves as indepen­dent and “in control” of their own models. Which one you use will depend on your corporate culture, structure, reporting relationships, and the personalities of the stakeholders.

One mistake that I’ve seen is to ignore the business itself and focus on dividing up the IT department into value streams. This is a pointless exer­cise since IT is typically not part of any value stream. Except in rare cases, information technology rarely adds direct customer value in a value stream. Do not start with IT.

Value streams are not the “only right way” to create segments. Sometimes value streams are already built into the structure of the company, which makes the process of defining segments fairly simple, but in many com­panies, it can be difficult to find owners for a value stream. This can reduce the architectural development effort to an exercise in frustration. Other times, value streams are too fine-grained to be useful; there is simply too many of them. One large corporation in which I’m familiar with had 22 business models, each with multiple value streams. A full value stream exercise would have shown over 80 value streams to be divided up among six enterprise architects. In that company, the team divided up the EA space into segments by business model instead. Most companies are not that complex.

In conclusion, focus your efforts on gaining adoption in one segment after another. Be strategic about which segments to gain a foothold in; use success in one to get opportunities in another. It is a good practice to use the logic of value streams (or business models) to create your segments.

Questions to consider:

• Have you mapped out the value streams of your organization? Do you know who owns success for each value stream?

• Have you had a conversation with each one of your value stream owners?

• Of all your value stream owners, do you know which ones are more supportive of business and enterprise architecture?

• For each value stream owner, do you know his or her single point of contact within the IT team? Is that single point of contact trained, aligned, and supportive of the EA goals and value proposition?

• Have you created a list of business segments from your understanding of the business and the value streams within the enterprise?

• For each segment, have you mapped out the impact of strategy on that partition? (This is a business architecture responsibility best done using capability heat maps.)

• Have you decided which architectural models are needed for each segment based on the needs of the people responsible for driving change into that segment; for example, can you justify every single model?

• Have you measured your capacity to grow? How quickly can you add business segments to the EA program? What will you need to do each time you add one?

• How well trained are your enterprise architects for delivering to the needs of various stakeholders? Do your team members have solid consulting skills? Stakeholder management skills? Situational awareness skills?

[For more from the author on this topic, see “Climbing the Ladder: 5 Steps to Connect EA to Strategy.”]