A model of an average enterprise is multidimensional. There are more than the three dimensions with which we are intrinsically comfortable or the seven that is the upper limit we are supposedly able to conceptualize. Optimizing our ability to manage in such a complex context requires that we integrate increasingly numerous specialized disciplines yet keep things simple enough to synthesize a ‘big picture’ view. Often, especially in the realm of Information and Communications Technology (ICT,) silos of implementation-specific or specialized knowledge and practice proliferate, complicating the task.
The focus of this and subsequent posts is on choices in ICT management and their impact on the quality of support and service it will be able to provide to the enterprise. An important point I intend to make is that Enterprise Architecture (EA) is critical to optimizing ICT’s value to the enterprise.
People responsible for running business units often complain that ICT is not connected tightly enough to ‘The Business’ and fails to understand, predict or accommodate their needs properly. On the other hand, enterprise management often complain that redundant and incompatible solutions to the same problem appear in different business units of their companies, complicating integration and creating excessive costs.
How can we structure and govern ICT in order to avoid these problems? ICT practice has swung like a pendulum between centralization and decentralization for decades and I sincerely doubt that there is any answer that has not been tried at least a couple of times in a few places and succeeded in some instances and failed in others. Regardless, I believe that EA is necessary to truly succeed in ICT at the enterprise level. Unfortunately, while good EA does not ensure success, poor or no EA can lead to failure in the longer term.
Enterprise Architecture: Describing the Business
An enterprise is driven by a hierarchy of concerns. At the top is Strategy—the markets and positions within them that are targeted. Subordinate to that is the Business Model—the products and the services it sells. Beneath that, the Operating Model—the capabilities and services needed to create, deliver and support them and, finally, Operational Architecture, the design for how to deploy people and assets to enable delivery of the capabilities.
This hierarchy, then, consists of WHY (the strategic assumptions on which the WHAT and HOW of the business are based,) WHAT (what it sells) and HOW (how it is produced.) Briefly:
- WHY (Strategy)
- What markets should we be in?
- How will we present and differentiate ourselves in these markets?
- Assumptions—what underlying assumptions are driving the strategy formulation, e.g.:
- Who are the customers in the markets we are trying to reach? What do they want and need?
- Who are the competitors and what do they make and sell?
- How do we compare?: Strengths, Weaknesses, Opportunities, Threats (SWOT)
- WHAT (Business Model)
- Products/Service Offerings, Business Units
- What products and services should we offer in each of our target markets?
- What characteristics must they have to be appropriate for the targeted markets/segments?
- Products/Service Offerings, Business Units
- How should the organization’s management and governance be structured to operate and oversee their delivery?
- Should we split the enterprise into separate business units with P&L responsibility for one or more products? If so, how?
- HOW (Operating Model)
- Required Enablers: Capabilities and Services
- What do we have to be able to do to deliver each of our products/service offerings?
- What specific competences are required?
- Which capabilities are unique and specific to the business unit or product/service and which are common and can be shared?
- What assets and infrastructure are required?
- Required Enablers: Capabilities and Services
- Operational Architecture:
- How will we structure the organization and allocate assets to enable our Business and Operating Models?
- People: organization design, assignments, roles and responsibilities
- Processes: how what gets done gets done
- Technology: applications, purchased services and infrastructure
- How will we structure the organization and allocate assets to enable our Business and Operating Models?
Enterprise Architecture is not based solely on a strict hierarchy. Products and services can bleed across elements of the strategy and share capabilities; people and assets can be shared among various parts of the business. While it is important to be able to trace the value chain from raw inputs to final delivery of a product or service, it is equally important to identify and document all of the places in which capabilities are or can be shared across products or services and among components of the organization. Understanding this as-is architecture is critical to enabling successful transformations that will evolve the business.
Enterprise Concerns
Successfully executing the strategy requires that the organization develop competence in a number of areas and meet various performance goals. Among them:
- Enterprise and Business Line Characteristics
- Financial Performance—the concern to which all others are subordinate
- Agility—the ability to evolve to exploit new opportunities and react to new threats
- Scalability—the ability to grow and shrink to adapt to changing market conditions
- Survivability—the ability to respond to adverse events and continue to operate at an acceptable level
- Market expectations
- Scenario development—the ability to enumerate and articulate scenarios to be included in the planning domain for the lines of business in which the company engages and those which it is considering entering.
- Risk Management
- Risk Identification and assessment—the ability to identify and quantify potential risks on a strategic and operational level
- Mitigation planning—the ability to devise approaches to mitigate risks and respond to adverse events
- Integration—the ability to incorporate risk concerns and management techniques into all three levels of the Enterprise Architecture model
- Information Security
- The ability to define how data on the organization, employees, customers, shareholders and partners will be protected and what policies and processes will be implemented to enable the protection plan.
- Costs and controls
- Cost projection and management—the ability to identify, plan for and control expenditures associated with operations.
ICT Concerns
Given what we believe the enterprise looks like today and what it may look like tomorrow, there are a plethora of decisions that must be made about how information technology will be acquired, deployed, managed and supported throughout the organization. For instance:
- Application systems
- What functionality must be supported?
- What non-functional requirements, such as integration requirements, must be met?
- Allocation to users—what can be shared and how?
- Operational support requirements—what will it take to run an application reliably?
- How should we integrate purchased, SaaS or otherwise outsourced applications and associated data?
- Infrastructure, network topology, implementation and operation
- Where, physically, are the people and assets that must be connected?
- What protocols, capacities, uptime requirements, levels of redundancy are required?
- What must we implement ourselves and what can we outsource?
- Data Stewardship
- Who ‘owns’ application data and who will be responsible for maintaining its architecture, ensuring its quality and maintaining its security?
- How will we ensure consistent usage so as to maximize data’s value?
- Who will be responsible for Master Data Management (MDM)?
- Technologies
- What standards will we observe? How will we accommodate services based on non-standard tools?
- How much and in what areas should we invest in research, experimentation and evolution?
- In-house vs. purchased services
- Application development and maintenance
- Operations
- Support—who will support operations and users?
The Scope of the Challenge
As you can see, the challenge is daunting. It’s often easy and expedient to throw money at a seemingly quick solution to an emergent problem, like purchasing a packaged solution that fulfills most, but not all, of a business unit’s need. However, it may also be that, in the end, expedient solutions contribute to clutter, excess costs, unnecessary complexity and reduced enterprise agility.
When the ICT management style pendulum swings toward centralization, there is a danger that bureaucracy will impede responsiveness and agility in the short term. When it swings toward decentralization, it minimizes bureaucracy but may lead to shortsighted, localized solutions that impede the enterprise’s overall agility in the longer term. Finding a sweet spot is the challenge that all CEOs and CIOs face. Unfortunately, the ‘right’ answer (and there may be a different ‘right’ answer for every company) may be the one that makes everyone the least unhappy, not one that will create a love affair between ‘The Business’ and ICT.
In subsequent posts, we will explore some of the choices and trade-offs that must be confronted and examine how the disciplines of ICT and EA are intertwined.