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.

Organizational Change Management for EA? Of Course!

One of the topics, although not new, that seems to be a regular topic of discussion among clients, peers, prospects and vendors is organization change management.  More specifically, how can EA be successful without an accompanying Organizational Change Management program?  Once you get into these discussions; however, the answer to the aforementioned question is “Yes!” but the discussion morphs into what we really mean by Organizational Change Management relative to EA.  Much like the term Enterprise Architecture, I think Organizational Change Management means a lot of different things to different people.  And also like the term Enterprise Architecture, I think there are some things that we can establish a position on to make the effort more meaningful and effective.

1. Enterprise Architecture defines the changes necessary to support strategic direction in 5 core areas:  Business activities, business information, application portfolio, data, and IT infrastructure.  The first two are the realm of Business Architecture, while the final three are the responsibility of ITA architecture, although this is for purely semantic and separation of responsibility purposes.  BA and ITA changes are related and should be coordinated accordingly.
2. Organizational Change Management is the process for altering other aspects of the enterprise that leadership need changed, such as the organization’s structure, resources, capabilities and behaviors.  These changes are necessary to enable and leverage the coming changes of the Enterprise Architecture.  This includes training for new skills, using new systems and information capabilities, identification of obsolete and new roles within the workforce, understanding the impact on the reporting structure of the enterprise, and introduction of new technology capabilities to the affected workforce.
3. Organizational Change Management, like EA, is not intended to concentrate on change within the IT environment, but rather holistic, enterprise wide change and the accompanying implications within a complex ecosystem.

In general, we believe that aspects of organizational change management happen as a byproduct of some implementation efforts, such as training for a new system, or part of a strategic planning effort, or even some mature HR programs.   But there seems to be a lack of systemic, coordinated organizational change management that is related to a corresponding EA program, introducing significant change into an enterprise.   We are not suggesting that EA teams take on additional responsibility, but like other necessary disciplines that have accompanied EA as a part of an enterprise’s significant transformation – governance, portfolio management, service management, and value management to name a few – EA teams can articulate and demonstrate the need for a professional approach to organizational change management.

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.

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?”

Communication Planning for EA

At the Troux Worldwide Conference in Austin 2 weeks ago, several questions were submitted by participants to my panel that we didn’t have time to get to.  Over the next few weeks, George and I will be addressing them.  One that caught my attention was the following:  “What style of communication have you seen be most successful?”

This is actually a topic I have written an article about, summarized below, as it is one of the most common topics that comes up with our clients.

Communication is a key to transforming an enterprise through strategic planning, enterprise architecture, and enterprise portfolio management.  Critical to the success and effectiveness of communication is planning why, how, when, and with whom communication will take place.  The answers to those questions are determined through communication planning.

Effective communication can often happen “off the cuff” or at the “spur of the moment”; however, relying on spontaneous effective communication will not likely sustain most EA efforts.  It is the responsibility of EA leadership to create and maintain a systemic communication plan to support the establishment, execution and effectiveness of the EA program.

Follow this link for the complete article.

Characteristics of Effective EA

There are a few characteristics of an effective Enterprise Architecture (as well as IT Architecture) practice and its artifacts that must be established and maintained throughout its existence.  In order to be effective, EA and ITA need to influence investment decision-making at the portfolio level.  This means being able to show the impact of investment alternatives across the enterprise, on other investment choices (including current investments) and over a longer period of time than just the current and next budget cycle.  Regardless of goals, objectives, industry, size, or stage of maturity, these 5 characteristics are necessary for effective EA and ITA to influence the investment portfolio:

• Business Driven
• Forward Looking
• Enterprise Breadth
• Maintains Linkages
• Proactive

Business Driven:  In order to be business driven, the EA program needs to involve professionals with an understanding of the operations and the executive leadership of the organization.  If you are architecting an enterprise, then your primary audience is the group of individuals with overall responsibility for the enterprise as a whole.  Your artifacts need to be able to communicate at the executive level, as well as create a forum for collaboration on the impact of strategy on the operations of the organization.   HL context models, relationship maps  and strategic capability change analysis are the deliverables that represent this characteristic.

Forward Looking:  Too many EA programs attempt first to impact implementation level decisions and projects.  While this is not only futile (one an effort is at the implementation level, EA impact is minimal at best), but also potentially dangerous.  Without an idea of the long-term direction of the business processes, information assets, business systems and technology, what meaningful and systemic guidance can EA or ITA provide at the implementation level, or even at the design level.  The architecture as a whole must be based on a consistent and portfolio-oriented view of how the enterprise will evolve as a whole over time.  This only comes from looking 3-5 (or more in some instances) years ahead.  Roadmaps are the deliverables that represent this characteristic.

Enterprise Breadth:  Many organizations have a history, sometimes successful even, of silo-oriented decision-making.  However, as complexity has increased and rates of change have decreased, the impact of silo decisions is being felt by these organizations.  And it is usually not a good feeling.  To combat this, EA must have an enterprise-wide scope to help senior executives understand the impact of decisions in one silo on other parts of the organization, because within the silo, this is not easily recognized.  And for the most part, if this perspective is not maintained by the EA group, it may not be evident anywhere.  This characteristic should be represented in all types of EA deliverables, providing the context to link artifacts from other levels of architecture (domain, solution, etc.), as well as planning  and development activities.

Maintains Linkages:  To increase the impact that the previous characteristics can have on overall effectiveness, the EA must establish and maintain both vertical and horizontal linkages in the participation and deliverables of the program.  EA is not responsible for the creation of every planning, design and modeling artifact in the enterprise.  But to increase the value of the lower level artifacts, as well as enable the impact of business driven, forward-looking, enterprise wide activities and deliverables; linkages across silos and domains and between levels of architecture must be established and maintained.  These linkages are generally represented in the overall EA meta model.

Proactive:  As I mentioned earlier, many architecture activities are focused on implementation and project level details, which is too late in the life-cycle to have meaningful impact without the benefit of process and artifacts that reflect the above characteristics.  Please don’t misunderstand my message.  EA needs to be able to impact the implementation and project level decisions, but not in the reactive way we see it happening in many organizations.  By creating teams, process and artifacts that are business driven, forward-looking, enterprise wide and maintaining linkages; EA can proactively impact the mix of projects and the implementation level design, technology choices and integration BEFORE projects are even started or implementation decisions are made. 

The true test of EA effectiveness is the ability to change implementation level decisions based on a reflection of what is in the best interest of the whole enterprise.  Without these 5 characteristics present, an EA program will struggle with that test.

Improving EA Team Performance

With the arrival of the New Year, many EA teams are in the final stages of setting their annual objectives.  This year, we find that many are being asked to perform at a level significantly higher than last year.   They must do so in response to higher expectations placed on them by leaders who believe that EA plays a critical role in moving the enterprise into the future.  

Many annual objectives documents are primarly structured as lists of projects  and deliverables that the team must complete in the next planning period.   While hard deliverables are necessary and expected, every EA leader should also consider adding objectives designed to improve team performance and to address “how” the team is going to accomplish their assignments.   Why?  Because EA success requires predictable and consistent performance by the team as a whole and by its individual members.

One of the most interesting observations from studies of EA team performance is that the typical team profile of a collection of highly skilled and specialized individual contributors isn’t necessarily optimal.  To be successful, teams populated that way must learn to function as a team, supplementing the natural tendency for individuals to work alone.  Enterprise architecture is inherently cross-domain in scope.  Only by working in collaboration across domain specialites will the team be able to quickly address the many dependencies that are part of the modern enterprise.   

We recommend that EA leaders employ the following techniques when striving to improve their overall team performance:   

Develop a common language: Words and concepts are important.  Adopt/adapt a “language of EA” that makes sense for your organization.  A common grounding in EA core concepts can go a long way to unifying a team.  Look to the more widely used and common industry approaches to EA, take a class, or ask us.  We’re happy to make recommendations on practical approaches that will work, and show you how to adapt them to your needs.

Be a Team: Get together frequently, in person and/or virtually.  Eschew “project status reporting” meetings in favor of strategic discussions, cross-domain issues resolution, trend analysis and healthy debate.

Collaborate and Communicate: Actively recruit and engage external parties and bring them into the discussion.  Learn to exploit “social media” style connections to engage with these larger audiences. 

Learn to Lead: EA is a “lead through influence” discipline.  Take a leadership course, but be careful to select one focused on “soft” leadership styles.  It isn’t about traditional personnel management techniques.

With people as the critical element to EA success; it only makes sense to invest in team skills and performance.   Unfortunately, many teams put disproportionate emphasis on templates, frameworks and deliverables.  Make it a practice to visit/revisit the health and productivity of the team.  Don’t wait until next January to start.

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?

Architect Roles and Relationship with EA

During the IASA World Summit in New York City last week, George and I were asked to speak about the different levels of architecture and the roles of the architects that work in those levels. The presentation is below. Slide 18 seemed to generate the most discussion with the participants. Remember that we are not talking about individuals or titles, we are talking about roles. Many individuals may fill more than one role, and one role may be filled by many individuals, regardless of title. All of the roles need to be filled, and in more mature organizations, the Architecture community grows and there may be multiple people in each individual role, with the coordination and collaboration across all levels.

Are all of these roles filled in your organization?

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!