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.

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.

Is EIA the Key?

As organizations continue to struggle with the complexity and amount of change to deal with, the EA team plays a crucial role in laying a foundation of adaptability for the organization to build from.  Once an organizations has done an acceptable job of providing a standardized infrastructure and at least basic governance of infrastructure standards, focus tends to shift towards the application portfolio and integration approaches.  This is natural and seems to conform to most of the evolutionary models of EA, such as the one from MIT Sloane CISR in Enterprise Architecture as Strategy.  However, I would like to provide you with an alternative to consider as I see organizations continually struggle with business units demanding more uniqueness to the functional systems they need to run their part of the business.

I think the key for some organizations to achieve a more adaptive environment is to focus on architecting the information and integration environments.  If information was more standard and consistent BETWEEN information systems with a common integration architecture (standard methods, components, messages, and middleware), then the information systems themselves could be unique functionally.  The architecture would need to provide the means of translating information formats and content from systems into the standard format and content for sharing outside the system.  This would also support SOA approaches, cloud computing strategies, mobility, and other approaches being pursued today.

As an EA team, are you focusing on the functionality of a specific area or are you leaving that to the project team, so that you can focus on the shared aspects of an application environment, namely the information assets and integration capability across the enterprise?

Getting Started with EIA – Identify High Level Information Classes

Recently, we have discussed the HL classes for Business Archtiecture (functions, processes, services) and Application Architecture (application classes and platforms) and Technology Architecture (domains and components).  Now let’s turn to Information Architecture, not Data Architecture.

In order to get started with Information Architecture, you need to identify all of the major “things” that your business produces or acquires information about.  We will call these information classes.  They are not databases or objects or  attributes.  They are conceptual in nature, but they represent the major entities that your enterprise requires information about.  These typically include entities such as customer, supplier, product or service, orders, items, employees, facilities, and inventory.  Of course, each enterprise may have their own language.  For instance, a financial services company may call their products by a different name, such as policy or account or fund.  And public sector organizations may not use the term customers, but rather citizens, constituents or voters.  And those in the healthcare related businesses would say patients.  In any case, you are primarily concerned with the group of people the enterprise is providing a service or product to, the sources of those products, and the major entitities involved in the production, stocking, logistics, ordering and delivery of said product or service.  You may have subclasses, as well, but for the purposes of getting started, we suggest no more than one level of decomposition.

Once the High Level Information Classes have been identified, they become more meaningful to EA work once you map them to the functional heirarchy and application classes. For more information and examples related to this type of information mapping, please see our Jump Start materials.