EA Tips: Anchor Models

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.

Too Much Tactical Focus with Business Architecture?

As more and more organizations embrace Enterprise Architecture with a concerted effort in Business Architecture (BA),. we are beginning to see one of the common pitfalls of IT Architecture (ITA) spill over — too much focus on the tactical, project level.  Apparently, getting business representatives involved in applying EA discipline to the business architecture does not mean that the effort will remain high level, strategic and forward thinking.  Just like many ITA efforts, BA efforts result in the identification of work that needs to be done to support the enterprise’s transformation.  And also like many ITA efforts, once the resulting work is started, many of the BA participants find themselves involved in the transformation effort.  Another factor that needs to be considered is the lack of dedicated BA resources, such as a Chief Architect or Business Architect or BA team.  The BA efforts are usually staffed entirely by a virtual team, all of whom have real, demanding full-time jobs.

If you are trying to avoid an overly tactical focus for your BA efforts, here are some suggestions to consider:

• Dedicated BA Resource.  A dedicated resource, not assigned to specific BA initiatives, but also not holding a full-time non-BA position is probably not feasible in many organizations.  However, those going through significant transformation efforts could easily justify a resource to keep pushing the transformation agenda, overseeing the BA initiatives, maintaining a focus on future change, and organizing and managing the BA virtual team.  If a full-time dedicated resource is not feasible, consider finding a leader who can dedicate some time to the effort, 25-40% minimum, while not getting deeply involved in individual BA initiatives.
• Strategic Agenda Items for Regular Meetings.  Most BA groups have regularly scheduled meetings, weekly, monthly, bi-monthly, etc.  By having every third or fourth meeting focused on new strategies, new technologies, new changes, rather than ongoing initiatives; the group will still be able to push the transformation work forward, while also continuing to architect the future business.  Another alternative is to always have at least one agenda item that is of a strategic, future oriented topic at each meeting.
• Maintain a Portfolio vs. a Project Perspective.  Rather than providing oversight to individual projects and implementation initiatives, focus on providing input to the investment decision-making function(s) of the enterprise, and track the overall portfolio’s progress against expected strategic outcomes.  Leave the cost, budget, resource, and schedule issues to the project management staff.

All of these suggestions are not new.  They are the same kind of actions that successful ITA groups have been employing to maintain a strategic perspective for years.

EA Tips – Style AND Substance

For an EA practice to be effective EA leaders must pay attention to both the “style” of how their team operates and the “substance” of the work they produce. While that guidance isn’t new, in practice I often find that many leaders don’t have the balance quite right. It is worth revisiting as a general EA Tip.

First, what do I mean by “style” and by ‘substance”? (note: I chose those words because it sounded like a catchy blog title) For the sake of this article, I define “substance” to be the “work product” of the team as viewed by EA consumers wanting hard deliverables like frameworks, models, standards, roadmaps, strategy papers, and other related content. “Style” refers to “how” the team works with the rest of the organization in creating and utilizing their content: engaging business and IT leadership, fostering a collaborative environment; choosing communications vehicles, the words they use, and the “posture” of how they present themselves to the rest of the organization.

Many EA teams disproportionately direct more effort to the substance of the work than to building a sense of ownership and socializing the desired changes. In essence, they under serve the “style” elements. Granted, substance is critical. No matter how good the soft skills are or how convincing the leaders are, if the content isn’t solid then nobody will follow. But what is more surprising to many teams is that even the most elegant and perfect deliverables often don’t have impact. Why? – Because the team hasn’t positioned the larger workforce to embrace enterprise architecture content and to use it in their day to day work.

Improving the EA team’s style is often where we spend time with clients, specifically working on the “art” of practicing EA. Though many EA’s wish there was a methodological approach to these softer elements, there really isn’t one that works in all cases. People, perspectives, culture, and individual skills vary widely from organization to organization. One approach is to look to lessons learned from the organizational change management discipline, particularly as they apply to driving change across and down into an organization. There are tried and true techniques for preparing organizations for change, conducting education and awareness campaigns, gaining support and participation, and communicating effectively through a variety of different channels. After all, one of the valuable outcomes from EA is helping an organization move from an emphasis on tactical execution and silo behaviors to one that includes a larger, enterprise-wide strategic element. Substance is great, but style really does matter.

EA Tips – Substance OVER Structure

If you read my post on “Style AND Substance” I stated that an EA team shouldn’t spend disproportionate energy on content creation without also paying attention to the many softer, stylistic elements associated with leadership and influence. One without the other and the team will fail. In this “EA Tips” post on “substance vs. structure” I offer that an EA leader should worry only slightly about organization and team structural issues and spend as many cycles as possible jump starting the EA team and getting them to work together to produce meaningful content (strategies, standards, roadmaps, etc.).

Every EA team I work with these days is overloaded. I believe that much of the time spent worrying about structure and organization is time better spent elsewhere. Yes, I know that there are just some HR issues that must be addressed, team members need job descriptions and performance plans, and frankly most people won’t even join a team unless they have a reasonable understanding of their responsibilities and how performance will be recognized.

Beyond that, though, I find that many leaders find themselves slicing and dicing roles too finely and creating a lot of unnecessary work for themselves. In fact, doing so often works against the team and inhibits their ability to be effective. The team becomes just a container for a collection of individual contributors, basically working alone and rarely interacting. The very essence of EA is that everything, in some way or another, depends on everything else. The more you separate coverage areas, the more difficult it is to stitch it all together.

Basically, I am saying to not sweat the organizational issues any more than you must to get a few strong players onto your core team. Don’t be too concerned about segmenting responsibilities discretely among domains. Let individual assignments adapt to the content needs of the enterprise and allow your core group to float among them, learning, growing, and sharing perspectives. Encourage everyone to work together as a team and dynamically rotate individual leadership and deliverable assignments. The team will be better off and the members will be as well, plus less time will be spent deciding who does (and doesn’t) do what and more time will be spent on results.

Federated EA in Larger vs. Smaller Enterprises

George and I are often asked ”How is EA different between smaller and larger organizations?”

There are a number of differences (amount of available resources, degree of complexity, flatness of the organization structure, number of elements in the application portfolio, etc.) that affect the approach, effectiveness, readiness and deliverables of EA.  But one that I think is one of the more complex to deal with and has the biggest impact on the effectiveness of, is the level of federation vs. centralization of EA.

In a smaller organization, there is much more of a tendency to standardize as much as possible due to the lack of resources for specialized technologies and skills and the propensity to outsource as much as possible, especially now with the progress of the cloud.  In larger organizations, there is usually a lot more inertia behind standardizing the infrastructure beyond the desktop, outsourced or not, while a lot of pressure from business users to have uniqueness at the desktop and within the application and data portfolios.  While this pressure exists from individual users or departments, there seems to be a lot more understanding within the business leadership that complexity and costs are getting out of control without more standardization of systems and data.  So the question becomes “What do we standardize and what do we federate?”

Three keys to being successful with federation decisions:

1. Understand your business’ operating model.  As discussed in a previous entry, the operating model concept from “Enterprise Architecture as Strategy” is a guide to the level of business process standardization (application standardization) and business process integration (data standardization) that the business requires.
2. Develop a capability map or taxonomy for your systems to identify the overlaps that exist within your application portfolio.  These capabilities tend to be a mix of functional (business) and technology capabilities that are delivered by automated solutions.  Using a simple matrix to relate your applications to the capabilities delivered by that application tends to be very revealing of the potential candidates for reducing redundancy.  However, capabilities are defined at a higher level than individual systems user requirements, to there is still going to be some compromising that is necessary when eliminating/replacing duplicate applications.
3. Don’t go overboard.  Not everything that could be standardized needs to be standardized.  Identify the areas that will have the biggest impact, whether that be cost savings or increased functionality or good will, and prioritize standardization efforts accordingly.

As you develop a better idea of what areas to standardize, you can begin institutionalizing your foundational architecture within the infrastructure, operations and development groups.  This will result in professionals in these areas spending a majority of their time on areas that are unique, and quite likely contribute to the competitive advantage of your business.

Mobility and Social Networking: Do You Have a Need for a Strategy?

Two of the biggest trends that many companies are addressing right now are mobility and Social Networking.  Maybe second only to cloud computing in hype right now, these two areas  represent significant opportunities for many companies.  However, one thing that I have noticed is that sometimes the trends with a lot of hype get a lot of attention when it maybe isn’t necessary in a particular instance.

Mobility is not just about providing mobile phones and other mobile devices to all or some of the workforce, but also understanding the security, information and process impact of having a mobile workforce.  Likewise, social networking is not just about marketing products through another channel or managing relationships, but also understanding the culture and demographics of your customers/consumers, suppliers, employees and partners.  So there is some significant thought that needs to be put into leveraging either of these trends for your enterprise.  The question to answer first is whether your business is one that can leverage them given the nature of the way your organization COULD work, given the right tools and applications.  In order to answer this question, which is not a technology question,  you must develop an understanding of business process and information flows in your organization’s operations.  Too often, though, we see the analysis in this area focus on one or both of two aspects:  1) the technology (hardware and software and network) and 2) current mobile workers and executives and social networking users.   The full potential here can only be exploited by understanding the impact of mobility or social networking on the operations of your company (how you design, produce, sell, deliver, and market your products and services) and the relationships that your company maintains.

While it is likely that either mobility or social networking can have a positive impact on one or more aspects of your enterprise, you must be prepared to look beyond the technology and current state of operations to leverage them.  Sounds like a job for EA.

Smart Grid and EA – Making Smart Grid Smarter

Many electric utility companies are in the process of fundamentally changing both their individual operations, as well as the electric industry as a whole.  Many of you have probably heard the term “Smart Grid,” but those in the electric industry are either embracing, waiting on or fearing (or maybe even a little bit of all three) the change that this transformation is bringing.  Essentially, Smart Grid refers to making the utility grid system of electric generation, transmission, distribution and consumption “more intelligent” with digital technology. 

The intelligence is to be supplied by two-way digital communications, digital sensors, and a host of intelligent devices such as smart meters, plug-in hybrid electric vehicles, improved substation machinery, and even consumer appliances.  So at first glance, Smart Grid may appear to be a vast upgrade of the utility grid infrastructure and devices.  While some companies may have viewed it that way to begin with, as they begin to look at the specific changes necessary to their assets, they are finding that there are many more fundamental changes needed in their business processes, organization, human resources, and overall business operations.  And many of them are finding their enterprise architecture program to be extremely useful in this endeavor.

Our advice to EA groups at electric companies has been to actively seek involvement in the Smart Grid initiative as early as possible.  While some have gotten involved early in the process and proven their value in the planning of the overall strategy and implementation trade-offs; others have gotten involved strictly as an IT advisor and planner, still showing the value of EA as they demonstrate the linkage between significant business decisions and IT investment options.  In any case, the participation of the EA group in the Smart Grid initiative seems to be increasing, and a variety of outcomes are being achieved.

EA groups are leveraging Smart Grid as the business justification for long-overdue communications network upgrades, common integration approaches and data standardization.  EA groups are pointing to business architecture methods and artifacts to help executives consider the impact of Smart Grid on their internal business processes, information flows, application portfolio and decision trade-offs.  In general, EA Groups are leveraging Smart Grid as an opportunity to do something they have always strived for — engage with business leaders on a topic in which the business has a strong interest and the EA group has a strong competency.  Many a utility company is finding this to be a win-win.

One last observation to pass along regarding the involvement of EA in such an apparent technology-oriented initiative.  As with many so-called transformations through technology, companies are finding out that much more than both the Operational Technology (OT) and supporting Information Technology (IT) need to change.  And in many cases, it is the involvement of the EA team that has demonstrated the future required changes to business processes, shared information, training, skills and competencies, and even the overall operating model of the company.

Using MIT CISR’s Operating Model to Drive BA Design

I have recently been working with a company that is getting their enterprise business architecture effort under way very successfully. One of the most successful aspects of their effort has been leveraging the operating model concept from “Enterprise Architecture As Strategy” by Dr. Jeanne Ross and others from the MIT Center for Information Systems Research (CISR). They have used this in 3 very distinct, but very effective ways:

1) They used the concept of the Operating Model as described in the book to help business executives better understand the relationship between how they run their business and the decisions that the EA should help them make.
2) They used the Operating Model as the basis of discussion with first the executive board, and then different business leaders across the company to develop a series of models that represent a high level vision of how they currently operate, and then also as a basis for their vision of how they want to operate in the future. The result was that they operated a variety of Coordination models, but with the help and guidance of the Business Architecture Team, they came to an agreement on the need for the Unification model.
3) And finally, and probably also most impressively, they used the Operating Model graphics along with a series of relationship maps to discuss, analyze and makes decisions about which business processes should be standardized, and which processes should be integrated with what common shared information.

Given the success so far, I am sure I will be sharing more of the aspects that have contributed to their success (org structure, participation, driving motivation to name a few); but for now I will leave you with this. If you are struggling with a way to discuss meaningful change in your enterprise, leverage the MIT CISR Operating Model.

EA Principles Have Little Value

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:

1. Ensure that ALL members of the core and extended EA teams understand what the principles really mean and how they are used
2. Be sure to actively and visibly reference the principles in the process of creating future state EA content
3. Refer to the principles and use them as a test in ALL solution architecture and coaching work
4. 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.

Social Networking – What’s good for them is good for EA

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.