Anchor models are context diagrams that capture the essence of the enterprise as a simple graphic. They should be equally meaningful to both business and IT personnel and should be so intuitive that they don’t require a multi-page text narrative to understand. While we see many models created by EA teams, most are lower level “IT” models of business systems or technology components. Even models that attempt to represent the entire enterprise tend to be IT-oriented. While these models can be very useful, they don’t serve the same purpose as an anchor model.
The term “anchor model” represents a concept, not a specific format. In our experience there is no such thing as the perfect template for an anchor model. The model must resonate with the broadest audience in as natural a way as possible. Therefore, the model should be in the language of the business it is depicting and is “good” only if it is meaningful to that organization. We have seen wildly different representations from different companies, yet each turned out to be exactly the right model. It’s one of those “you know it when you see it” phenomenon. When it is right, the model just makes sense.
Anchor models are basically top-level context diagrams describing the “enterprise”. They go by various names: company on a page, enterprise value network (EVN), concept of operations, operating models, root models, etc. These diagrams serve multiple purposes:
- As a consistent view of the company – a context for common understanding, language/terminology, etc. It allows everyone to get on the same page in the simplest, most direct way possible, representing a “big picture, enterprise view”.
- As a root for other derivative models (business, information architectures, business capability portfolios, etc.)
- As a credibility building tool for the IT executives in interactions with their business counterparts
- As a base model to super-impose various information systems, exposing overlaps, duplication, etc.
Creating a “good enough” initial anchor model is more art than science. It is a people-driven, collaborative exercise. A “starting point” model created by a sponsor usually helps kick off a productive session. We consistently observe several behaviors associated with the process, both good and bad, and have several tips to help you. Here are just a few:
- Anchor models can be controversial and are challenging to create. Don’t let that stop you from trying.
- Find passionate, business-knowledgeable people to start. Ideally, an anchor model should be something created by the business, not IT. An EA group is often the instigator to its creation and should act as catalysts to the process and not owners of the model.
- Not everyone is going to be happy. Someone will always object to something in the diagram, and the tendency is to just “make it a little better”. Our advice, work in a small group and time-box the activity. We suggest a few hours initially.
- Keep it simple, simple, simple, including only the significant parts of the organization. Resist the tendency to try to include everything a business does.
- Look at value networks, internal and external to the organization. Expose internal functional blocks, flows of information and services in/out/between them. Include the full range of external stakeholders and the interactions with them in the diagram (customers, suppliers, partners, regulators/government, etc.)
- Catalog your desired “functional hierarchy” to understand the main business functions performed. Avoid organizational constructs (departments, divisions, etc.). They are fluid and will undoubtedly change. Make your models as timeless as possible.
- Relationships are at the heart of anchor models. Understand the flows of information (not data models) and how functional elements relate.
- Timing is everything. We have seen good anchor models get no traction when presented to the wrong people at the wrong time.
There are many more tips that we can suggest. If you have a successful anchor model that resonates with your business, let us know. We’d like to hear your experiences and will share any other general pointers back to the community.
A strong anchor model, once complete, appears so obvious that many wonder why it was created. But that misses much of the point. It is the process of creating it that often yields the highest value.
5 thoughts on “EA Tips: Anchor Models”
It would be helpful if you shared a few visual examples of some Anchor Models.
Hi Brian – good to hear from you. You are the second to make the comment but that, at least, means that people are reading the post. I am curious how many others do the same – maybe I did blow it. Please see my previous reply to Roland and I offer you the same thing I offered him. These are very powerful models when it all comes together and I encourage everyone to have one. I can send you the EVN documentation as well, and if you are interested, we can catch up offline and I can show you some of the others.
Hi Roland. You are correct, I did not show a model and I made that choice intentionally. As I said in the post, each company-on-a-page model looks wildly different than the next, both in substance and more importantly, in style. The best models are created collaboratively by a group of participants starting from a clean sheet of paper with a set of rules they should use, with the task to create a picture that captures the essence of their company in a way that resonates for them. When I show one in advance it tends to bias them in unproductive ways. That might be intuitively murky. Some think that they must have a starting point but in my experience that actually works against them. A big whiteboard and many colored markers, and most importantly, an eraser, supports the brainstorming activity that often yields surprising results. Maybe I am overly optimistic, but I have been more successful that way than not. I usually ask people to, without any prep, “draw a picture of their company for me” then I start throwing the rules at them in the form of the questions I included in the post – what are your major business functions and how do they relate and interact, how does your business relate and interact with your external stakeholder communities, what value/products/services does the company produce, etc. The result is a better, more natural model they can use.
Perhaps my approach in the post was a mistake. I’ll be curious to see how many other comments I get. Note I did ask readers to share their examples as well and will share any non-proprietary ones I receive (though as a rule, once organizations create them they tend to NOT let them be shared). If you are interested I can send you an example of the concept of the Enterprise Value Network (EVN) model I described. It is a functional starting point that helps some people think it through, though it is never pretty and doesn’t usually resonate with anyone other than the people that created it. Let me know.
George, good approach. I’ve used it for many years and many more trying to convince ‘upper’ mgmt (shld I say “dummer”). My point is that many groups may lack a full view of the mission they are engaged in and their difficulty is that they view things with myopic eyes consequently they resort to model the convergence of the operational and the technological aspects. Anchor models are great to engage business people as well as IT execs, these are the ones that speed up the approval of it; however, a good EA Architect must participate in the strategizing of the approach with the business. EA is a composite or collage of independent models that are sawn together by their affinity or functional relation with other models; one can see at any time a perspective of a given function and see who, how and what participates. Ordinarilly it takes me 5 yrs to do one but presently I have in an effort that is taking almost twice as much, simply because of being too vast, too many businesses that want to do their own thing and expedite result, and driven from outside sources; a very difficult situation.
George, I like your response to Roland. After hearing about anchor models at the EAC a few years back, and seeing an example from the Government of Ontario, it was a challenge to forget what I saw and not influence the others in our group. Each business, although usually after the same goals, can operate in radically different ways. I believe that this is why so many organizations struggle to find a way in which to describe their architecture. Many organizations approach the problem the same way the have apporached many of their problems… “Let’s find and example, and make it our own…”. I feel that the answer to many businesses needs to be approached in a different way or manner than the way in which the approached creating their business in the first place.
P.S. I don’t believe your approach was a mistake… it only proves your point, any example, no matter how sterile, will more than likely be a false start.
Comments are closed.