EA Tips: Anchor Models

November 7, 2011

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?

July 12, 2011

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

July 12, 2011

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

July 12, 2011

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

July 12, 2011

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?

February 8, 2011

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

October 4, 2010

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.


Follow

Get every new post delivered to your Inbox.