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.

George Paras and Tim Westbrock featured guests on A&G Webinar Nov. 16

Join George and Tim for a webinar on November 16, hosted by A&G Magazine.  We’ll also be joined by special guest Dave Baker, a longtime friend and industry colleague from PwC.

We’ll review the findings from the A&G 2011 Year-End Survey, discuss trends we see shaping the role of enterprise architect going in to 2012, and answer listener questions.

Follow this link to the Architecture and Governance Website for more information and to register.

Tim Westbrock to Speak at IT Leadership Forum, Dec. 13, in Atlanta

Join Tim at the IT Leadership Forum, Dec. 13, in Atlanta, sponsored by alfabet.

Tim will be presenting “Expanding Enterprise Architecture into the Business.”

The ultimate promise of Enterprise Architecture has always been the alignment of business and IT strategies, activities, assets and direction.  In order for EA to bridge the gap between the desired business future state and the work that must be done to achieve that future state, EA must evolve to include a business architecture sponsored by business leadership and developed by business professionals.

Tim will facilitate a discussion on the many facets of business-enabled EA, while also adding their experiences relating to the challenges of approaching the business, how EA and ITA work together, the goals, organization and outputs of a business enabled EA approach and how to get started.

This is an invitation-only event, so if you are going to be in the Atlanta area Dec. 13th, click here to get more information on the event and how to register your interest in attending.

Hope to see you!

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.

Why No Business with EA?

So there I am sitting on a panel at the Troux Worldwide Conference a couple of weeks ago, answering interesting questions with some interesting co-panelists, when a thought struck me.  “After decades of positioning EA as a discipline for business-IT alignment, why aren’t EA programs more in tune with(driven by, owned by, participation from) the business?”

I’m not just talking about myself positioning EA in this way.  Just about every definition you come across, from vendors, consultants, analysts, and practitioners alike; EA is described as being business driven, strategic in nature, and focused on the long-term future state of the enterprise.  But within most organizations I engage, EA is found to be lacking significant business drivers, business participation or even any level of credibility from business executives.

So I ask again, Why?

I think that there are a variety of reasons for this, and the exact mix of reasons are probably unique for each individual enterprise.  However, I would guess that there are a few factors that are predominant in most organizations.

1. Lack of EA leadership within the IT organization.  I don’t mean that there are no leaders in IT.  I mean that the leadership in IT for EA (let’s face it, most EA organizations are within the IT function) isn’t doing what is necessary to form the relationships and value proposition for EA to be relevant outside EA.  They remain satisfied with a focus on IT outcomes – applications, infrastructure, standards and governance.
2. Lack of business understanding within IT and EA leadership and practitioners.  IT leaders and EA program members must develop an understanding of the core operations, motivational forces, financial model, and strategic plans of the enterprise.
3. Lack of translation of business understanding.  Some EA practitioners have made the initial investment in gaining essential knowledge about the business in which their enterprise competes, as well as the internal operating and financial models, and their strategic drivers.  But the next step is the critical one.  They need to create artifacts that represent that understanding in a way that communicates with senior executive leadership.
4. Too much responsibility at the project/implementation level within IT.  Time and time again, we see very capable EA teams try to gain credibility by helping out as an added resource/technical lead/project manager; only to be given these responsibilities as a permanent part of their charter.

While there are other reasons that warrant consideration (lack of understanding/approval by the CIO, wrong personnel involved, economic downturn); the above represent the factors that demand focused effort to overcome.

What can we do to change this?  Here are a few suggestions:

• Read books and industry literature of a non-technical nature about the industry in which your company competes.
• Experiment with different types of high level models that represent your understanding of your business’ current and potential future state(s).  There are no commonly accepted formats and nomenclature for these types of models, as they are dependent on the executives you are trying to communicate with.  And do not be afraid to have different models to communicate the same thing to different audiences.
• Understand the financial model of your enterprise and how it impacts IT’s value delivery.  You must develop a contact in the CFO office.
• Resist project level responsibilities for your EA team.  If you have to accept them for a short time, develop a plan with your superiors to instill architecture skills into the project delivery staff.

Location, Location, Location – Where Should an EA Team Report?

At the recent Troux Worldwide Conference in Austin I moderated two panels, one on Top Performing EA Teams and the other on EA Leadership. We had many questions submitted by audience members and were unable to answer them all. In the next few weeks Tim and I will be offering our perspectives on some of the questions the panels didn’t have time for and share thoughts on a few they did. “Where should an EA team report?” was one of the latter.

It seems that many EA teams we talk to ask about reporting structure, either as reinforcement that they are in the right place now, or as justification for reorganization if they are not. If I had to answer, without knowledge of an organization’s specific circumstances, I would say something like “given the latest trends in enterprise architecture towards stronger business architecture, the EA Team should ideally report directly to the CEO or executive committee in some form of a strategy function”. This gives the team the imprimatur of executive authority, strong visibility, and broad reach across business and IT concerns – truly the “enterprise” perspective.

But that answer isn’t realistic in most current organizations. First, we’d have to establish that the team is really doing true “Enterprise” architecture vs. IT architecture. A good discussion on what we mean by this is included in Tim’s blog entry from last year on The Transformational View of EA. Transformational EA specifies business architecture that is owned, driven, developed and maintained by business people as opposed to their IT proxies. It is coordinated in partnership with IT architecture-oriented EA’s focusing on the IT and systems-oriented perspectives. Until that happens it is unlikely that an EA Team will reside at the level of my answer above. If it has happened already, they have probably been moved up to that level or are already well on their way.

The question most EA teams should ask would be “What is the best place for EA to report in MY organization and how do I get there?” The first part of that is a much more straight-forward question to answer. For a Team working on IT architecture the best place to report is directly to the CIO as part of an Office of the CIO, along with the PMO, IT Strategy Group (if not already the EA group), and other CIO functions. This positions the EA team organizationally on par with operations/infrastructure, security/compliance, and development/support.

Many EA teams find themselves deeper in an infrastructure group doing technical architecture or as part of development support organization. Is that bad? Not necessarily. It is the starting place for many EA Teams. It’s only bad if the scope and scale of the team’s reach is constrained by it. I have seen cases where the EA team administratively reports into a supportive infrastructure director (or development director) who recognizes the value of EA, their role, and gives them license to practice something closer to holistic, forward-looking, business-driven EA. After all, good EA teams are not self-contained. They are highly dependent on engaging a virtual community of stakeholders and contributors from across the organization. Where the team reports, provided again that the leader is supportive, is less important than what it does and how it reaches out to influence others.

So, the bottom line answer to the question of where an EA team should report cannot be from a purist perspective but instead should be based on a combination of practical realities along with the vision and aspiration of the team to drive value. Whenever I hear the “where SHOULD we report” question I prefer, instead, to deflect it and work with the team to answer the question “how can they drive maximum value”. If they can’t do it where they are then we determine, realistically, “where COULD they report”, and “what will it take to get there?”

IASA Chicago Chapter Inaugural Event April 7- George Paras Featured Speaker

Thursday evening, April 7, marks the inaugural event for the new IASA Chicago Chapter.  The meeting will be from 6:00pm-7:30pm at Illinois Technology Association (ITA), 200 S. Wacker, 15th Floor, Chicago.  The new chapter provides a networking and educational forum for IT and Enterprise Architects from across the Chicago area.  I will be leading a session on “Changing Architects’ Conversations”, sharing tips and techniques on how architects can create and take advantage of opportunities to engage enterprise leadership in strategic conversations.

In addition to speaking at the event, I am honored to have been asked to serve on the Advisory Board for this new chapter.  Please invite your architecture colleagues to come and join us!

Event and Registration Details

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.

Top 10 Things an EA Should Be Thinking About (Part 2)

A couple of months ago, we published part 1 of Top 10 Things an EA Should Be Thinking About.  Now we add a few more, with considerations for the New Year.  To get started, I will repeat what we said in part 1 as the means of introduction…

…Our list represents the Top Ten (or so) things that we think true Enterprise Architects should be thinking about.  As always, this represents our thinking that Enterprise Architects should be focused on the whole of the enterprise, business and IT perspectives, long-term business strategy and transformation, and the impact that has on the work that needs to be done beyond the here and now.  Not the kinds of things that solution architects, data architects, application architects, infrastructure architects, or security architects should be thinking about – What should ENTERPRISE architects be thinking about?

Not listed in order of importance – they are all important.  Also, we would like to tell you that a typical IT-centric Enterprise Architect may not be able to answer these questions or think about them as completely as they should – in which case, they need to seek out the appropriate business and/or IT professionals to discuss these topics with from the perspective of their enterprise.

6.  With increasingly creative business partnerships forming in the marketplace, how can we effectively share information and collaborate with partners while protecting business confidentiality and adhering to regulatory concerns.  Are there general rules we should develop?  This is a dilemma of the new century.  The types of partnerships forming between suppliers and buyers, between former and even current competitors, between public entities and constituents, and between producers and consumers are primarily being created to share/consume information rather than products and services.  Another factor to consider is the element of trust, as the use of information outside the enterprise boundaries may be impossible to monitor and control. 

7.  As increasing amounts of information about customers, markets, transactions, sensor status, etc. flow into our company, are we able to effectively analyze that information to increase profits and/or value to our constituents?  Can we handle it, manage it, store it, protect it, etc.?  Which work processes must change or be invented to operate in the new environment?   The amount and size of data are increasing at a tremendous rate for most companies.  While the hardware to move, secure and store this data is an issue in and of itself, the more pressing issue is how to utilize the information to your enterprise’s benefit.  The focus needs to be on the information consumers.  Who can use the information to support their work activities and/or decision making processes?

8.  How does our enterprise “measure” or represent value?  What are the most important factors of success to our executive leaders?  Are they being measured?  How can EA facilitate the achievement of those success factors?  We are often asked how to measure the value of EA.  Short answer: Measuring EA’s value is dependent on the measurement of value in other activities influenced by EA, and most organizations are not mature enough in their general performance management capabilities to support the ability to measure the value of EA.  So the workaround is to figure out how EA can enable those factors that are most important to executives and show the indirect linkage that EA has to contributing value.  But it all starts with understanding what your executives value.

9.  With the current aggressive pace of marketplace and technology change, have we made the right decisions to be nimble enough to respond ahead of our competitors?  How important is agility to the business and are we prepared to be innovative?  How can I make the enterprise understand the need for adaptability?  This is not a NEW question, by the way, as those of you who have followed us for the last 15 years know.  But as time goes by and these paces continue to accelerate, these questions become even more important…as we have been saying for the last 15 years.

10. Where are the decision-making bodies and processes disconnected in our enterprise?  And once you identify them, how can you create a visualization of these broken chains?  EA is part of the planning and decision making ecosystem of your enterprise.  Influencing decisions and plans for investments and implementations is the outcome of a well functioning EA program.  In order to do this effectively, you need to identify where to influence these decisions and convince executive leadership that EA has a place in the process.

We would love to hear what are readers are thinking about in 2011.  Please share with your comments.

EAdirections’ Views on Business Architecture at Troux Worldwide Conference

Tim Westbrock will be sharing his views on Business Architecture with attendees at the upcoming Troux Worldwide Conference in Austin on March 23rd and 24th.  For those able to attend, you will be intrigued by Tim’s perspectives on Enterprise Architecture as it is commonly practiced today and on his thoughts on how the discipline of EA is fundamentally altered by the addition of business architecture practices.

George Paras will also be in attendance, serving as Master of Ceremonies for the event in his role as Editor-in-Chief of Architecture and Governance Magazine, the event’s main media sponsor.

We both look forward to the opportunity to meet with our subscribers and blog readers while in Austin.  If you plan to attend,  please contact us ahead of time and we’ll be happy to arrange for a time to meet, or just be sure to come up and say hello at the event.  

Here are some more details:

The Troux Worldwide Conference is a must attend conference for companies involved in Strategic IT Planning and Enterprise Architecture (EA) programs. Set for March 23-24, 2011 in Austin, Texas and sponsored by Architecture and Governance Magazine, the conference will include some cutting edge case studies from some of the most innovative and successful companies in the industry.

This is your chance to hear the latest on how to make your EA programs sing with success and most importantly – deliver value!

The Troux Worldwide User Conference is also a great opportunity to network face-to-face with your peers and industry thought leaders. For more information and to request your invitation, please visit www.troux.com/conference