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.

Better or Different? An Argument for Adaptability

As a primary direction to create and sustain competitive advantage, some executives have decided it is more important to be different, than better. This is not to say that there is no consideration for operational efficiency, only that it is not the primary driver for many companies seeking sustainable competitive advantage.  Many market leaders separate themselves from their competition by operating differently, offering different services, delivering via different channels, providing different information or producing different products.  Because success breeds imitation, many competitors will change also, eliminating the differentiating factors.  In order to sustain their advantage, companies must differentiate themselves again and force the market in which they compete to continually react to their changes.   Consequently, executives of competitive differentiator companies understand the need for an adaptive environment and have enabled corporate agility with an adaptive enterprise architecture (EA) strategy.

What is Competitive Differentiation? Companies with a differentiation strategy strive to provide uniqueness in their industry along dimensions that are widely valued by buyers.  They position themselves to provide one or more needs that buyers perceive as important that is different from the competitors in their industry or a specific focus within that market.  Differentiation can be presented through a product or service itself, the channels through which the product or service is provided, marketing, procurement and other factors.  Each industry has its own factors for differentiation.

Competitive differentiation strategies require faster than average business process change and high demand for information access, both requirements for an adaptive EA.  For instance, one market leader has an internal metric for measuring its business process change rate — with a goal of once every 6 months.  This compares to the average of once every 12-18 months for other fast-change organizations.  This company, like others engaged in competitive differentiation, has placed a high priority on developing an adaptive EA to facilitate this degree of rapid change.  The need for information access is derived from the requirement for faster decision making among hyper-competitive organizations.  Providing access to the right information to the right people at the right time becomes a key architectural requirement.

The key linkage between the business and enterprise architecture is the identification of the fast-change business capability changes and the parallel business information capability changes affected by the competitive differentiation strategies.  Not all processes are affected as dramatically as others by differentiation.  For example, a manufacturer that is differentiating itself through multiple distribution channels is more likely to have fast-change within the processes that interact with distributors and customers, rather than its internal manufacturing process.  This change will also impact the type and amount of information that is shared between the manufacturer, distributors and customers.  Likewise a manufacturer striving for competitive advantage through product differentiation would impact engineering, design and manufacturing processes more than customer service, accounting and billing, while increasing the amount of information sharing necessary between product designers, engineers and the manufacturing floor.  The impact of these fast-change strategic capability changes on EA is that they become the basis for the common set of drivers which the business and the IT organization agree to pursue with their EA.

Is your company pursuing competitive differentiation?  How is that effecting your EA plans?

Things EA’s Should Think About – External Collaboration

One of the many interesting outcomes of today’s business climate is the increasing variety of new business partnerships. Traditional boundaries between organizations are giving way to innovative and creative relationships, driven by a combination of necessity and opportunity. Cross-company information exchange and collaboration is the central success component.

Organizations are discovering that there is often more to implementing these partnerships than is apparent at the outset, and the issues multiply with each new relationship. For example, “How can we effectively share information and collaborate with partners while protecting business confidentiality and adhering to regulatory concerns”? Those are just two among many important considerations. Issues intrinsic to external collaboration have far-reaching implications. Identifying and addressing them is tailor-made to the broad, cross-enterprise, cross-domain perspective and analyses that an EA group can bring to the table.

Many organizations are discovering that the volume of requests to share information is increasing with each new business partnership, as is the type of information exchanged. Increasingly, they are seeing demand for bi-directional collaborative interactions, in near real-time, and with a frequency that makes it difficult to respond in time to address the market opportunity. Furthermore, these collaboration requirements are contextual and don’t always fit into a standardized approach. Not only will different companies have different needs, but it is likely that there will be many different models even within a single company based on the type of partnership and the participating departments. Some cross-organization collaborative examples we have seen include legal negotiations, multi-company engineering activities, resource scheduling /provisioning, joint marketing initiatives, barter arrangements that include trading excess production capacity for a right to access an organization’s client base in a foreign market, and many other variations.

It is likely that a single standard solution cannot address the full range of scenarios an organization might encounter. The EA group should work to raise the visibility of the most pertinent issues. They should guide the creation of a general framework, including a set of rules, principles and approaches that can address them. Here are just a few of the questions organizations we work with are beginning to ask:

• What is the business vision for partnerships? How will they grow and evolve? Where do they fit in our overall enterprise model? Which business processes, business functions and information areas are involved? What is the business value to enabling these partnerships?
• What confidentiality, proprietary, legal and regulatory issues are relevant? What other business risks are in play?
• What patterns of external collaboration exist with potential partners? Are there standardized business patterns and collaboration models that will broadly satisfy business need?
• How should external collaboration integrate with our own internal collaboration models and enabling infrastructure? Should it? Do we grant access to external parties?
• How do we protect our proprietary and confidential information from being intentionally or accidentally passed on to other parties? How do we protect theirs? Do we restrict unauthorized copying? Do we lock access, encrypt, etc.?
• How do we address different data definitions, data security zones, data classifications, etc.?
• How do we ensure timely and scheduled updates to our partners? How do we alert each other to changes? How do we ensure partners are not working with expired information?
• Etc.

So, what should enterprise architects do? Get ahead of the conversation, not so much that you get tuned out, but enough that you begin asking the right questions to gauge the enterprise need. Use a multi-pronged communications approach to get the conversation started with business leaders, IT leaders, your own team and other stakeholders. Techniques can include individual discussions, facilitated sessions, and internal social media postings. Once you get a sense for the appetite of the enterprise you may see traction develop. Begin to create hard artifacts for discussion; capabilities analysis first, then principles, then iteratively build increasingly detailed models, specifically business architecture models. Remember that, at any time, you may get too far ahead for anyone to care. You can always park your work and come back to revisit later.

External collaboration is just one of the many questions that enterprise architects might want to think about in the next year. A proactive EA group’s role is to be thinking about high impact, enterprise-wide constructs at least in enough detail to have an appreciation for the issues, the scope and scale of possible approaches. Doing so will inform the organization enough to make the proper decisions when time becomes the critical constraint.

Common Denominator: Business First!

I am working with a couple different clients now on their approach to enterprise architecture, and not surprisingly, their approaches are vastly different.

One company has a core group of EA’s, working primarily on what they have named Business Driven Target Architecture, which is a bit of a mix of business, application and data architecture.  The scope of these ranges from very project-specific to business-unit wide.  In addition to this work, they have other efforts underway to cross-reference their primary work with each other, company and division strategies and trends in business and technology.  While their primary work is very solutions oriented, their secondary work is enterprise-wide and will, over time, provide more enterprise views of the business and application landscapes.  There is another group that is focused on the technology architecture. 

The second client also has two groups working on EA. The first group has been in existence for a few years and is an internal IT group, headed by the full-time Chief Architect, with several architects acting in a part-time EA/part-time solutions architect capacity.  The Chief Architect leads the IT architecture effort with internal IT resources , but also is a member of the second group.  The second group is composed of a variety of business and IT representatives, with a focus on business architecture and strategy.  Without the second group, the internal IT group has struggled  to gain the traction necessary for EA to be more effective.  The second group is just getting started, but they are already beginning to see more support, especially given the stature of business architecture group’s members and the vocal support of the company’s chief executive.

While these two companies are approaching EA very differently, they both have one very important characteristic in common: They both have a “Business First” approach.  The first company starts their Business Driven Target Architectures (notice the First word in the name of their approach) with an understanding of the business goals and strategies, pain points, processes and business capability changes.  That is what separates it from a straightforward solutions architecture approach, in addition to the cross-referencing to their secondary work.

The first company, after struggling with traction, also decided there needed to be more of a business first sense to their efforts.  So they not only created a Business Architecture Team (there is that word first again), but they also focused the group on defining a holistic business operating model as the context for many of the business process integration and business process standardization (see my earlier post that describes their approach) recommendations.

Both of these companies will continue to modify their EA approach as necessary, but one thing will remain constant: Business First!

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.

Transformational View of EA

OK, so you think you are practicing Enterprise Architecture, right? As I have pointed out before, the key is the answer to the question, “Are you architecting the enterprise, or are you architecting IT?”

As I dare say, most of you (if not all) would answer honestly that you are architecting the IT environment (apps, data and infrastructure), albeit with a significant alignment with the business of your enterprise. In any case, as I have been having this conversation with audiences, practitioners and clients over the last couple years (or even longer as a client of mine pointed out yesterday – Thanks, Marc!), I have been suggesting that true EA requires business-owned Enterprise Business Architecture (EBA) and Enterprise Information Architecture (EIA).

The implication of this suggestion is that the EBA thought of in the traditional sense is not within the domain of IT; but rather owned, driven and primarily developed and maintained by a group of business professionals within the enterprise. Further, there is also a separation of EIA and Enterprise Data Architecture, with the former under business direction and the latter under IT direction, joining EA efforts for application and technology. Figure 1 depicts the relationships described above.

There is a role for IT EA professionals to play. As the figure suggests, a relationship exists between the business domain and IT domain. Initially, the IT architects must translate the impact of the business and information domain upon the architectures within the IT domain. This is done primarily through modeling and capabilities analysis, a topic for another time. IT professionals have the modeling experience, plus a vested interest in the outcome of the business and information architecture efforts, to be valuable members of the team working on the business domain architectures.

Recently, I have been working with an organization going through a significant transformation and they decided to do exactly what I have been suggesting. A group of business representatives including IT representation, lead by a representative of the executive leadership team, has taken ownership of business and information architecture to define how the business will transform. It will then become the IT Chief Architects responsibility to lay that business blueprint on the IT landscape to translate the changes necessary within IT to support the business transformation.

Let’s hope this is the beginning of a trend.

Webcast on Business Architecture

We have made our position pretty clear on this topic, but  just to make sure everyone caught it - We think that 2010 marks the year that Enterprise Business Architecture has finally become a legitimate concern for a singnificant number of organizations, probably more than a quarter of organizations practicing EA. 

To further clarify some of our thoughts, George and I sat down and recorded this webinar. 

EAdirections On Business Architecture

View more videos from Tim Westbrock.

Let us know what you think.

Business Architecture Discussions Continues with The Open Group Seattle Conference

Last year I mentioned that I attended The Open Group Architecture Practitioners Conference In Toronto and that I was very excited about the direction that the conversations went – namely the need for EA to become more of a strategic business discipline.  This month, I attended the version of this event in Seattle.  Again, I was encouraged.  This time by the theme moving past need and into practice.  The plenary sessions, which are the general sessions that are open to Open Group members and non-members alike, all focused on moving EA away from IT and towards the business.  With titles like “Changing the Conversation” and “The Language of Business Architecture” it is obvious that the conference tried to get people to think differently.  Some of the side tracks also promoted this concept, such as “Business Driven SOA,” “Translating Business Speak into IT Speak” and “Presenting EA to C-Level and The Board.”  Hopefully, they will continue and others will follow. 

My presentation was part of the “Language of Business Architecture” session, focusing on the dynamics and language of Business Architecture as it evolves from a commonly-accepted, but scarcely-executed domain of EA into a necessary part of a compelling and successful business transformation effort.  The presentation is available here. 

Also, following my presentation, Dana Gardner of Interarbor Solutions interviewed me for the BriefingsDirect series.  The topic of the conversation centered around the points that I made during my presentation on the language of business architecture, relaying the effectives ways that organizations can become successful in the development of transformational enterprise business architecture.

Click here to listen to the podcast.

Click here to read the transcript.

Business Architecture vs. IT Architecture

We are finding Business Architecture (BA) to be one of the most misunderstood but high-profile interests of business executives, CIOs and enterprise architects alike. They are asking questions like:

• Is BA the key to enabling business transformation through an enterprise (EA) effort?
• Does everyone have a business architecture?
• Is it owned and driven by the IT organization or the executive leadership of an organization?
• Can you truly enable business transformation with an IT-centric view of Enterprise Architecture?

For decades what IT professionals have called Enterprise Architecture is actually IT architecture. What we see most of the time is an EA effort mostly, if not solely, conducted within the IT function. There are certainly benefits to be achieved from IT architecture – improved adaptability, standardization, cost reduction, reduced integration complexity, and quicker time of delivery tend to be the chief objectives of most IT-led EA efforts. However, the lack of business participation, especially from those with strategic leadership, and the lack of distinction between BA and ITA will keep EA efforts from truly supporting or even contributing to an organization’s transformation efforts.

EAdirections is exploring three perspectives of the structure of EA from traditional to transitional to a truly transformational view. They will demonstrate how you must evolve the view of enterprise architecture as you go through different stages of maturity:

• How the Traditional View of EA supports the establishment of a strong IT foundation for the enterprise
• How the Transitional View of EA enables a more adaptive and agile foundation for quicker solutions delivery
• How the Transformational View of EA leads to true business transformation

Some EA efforts evolve to become more transformational based on the need and request of senior leadership seeking help with major business transformation. However, most EA efforts are going to have to develop the models, language and value proposition in order to get business leadership interested in architecting enterprise business transformation.