Feature

posted 5 Aug 2005 in Volume 2 Issue 2

Developing an enterprise architecture

Establishing and applying best practices throughout the One Vodafone initiative. By Adrian Grigoriu

Vodafone has become one of the world’s largest mobile-communications communities with 154.8 million proportionate customers, equity interests in 27 countries and partner networks in a further 14 countries. To keep up with this demand, we wanted to deliver a single customer, partner and vendor proposition across the entire (and vast) group footprint. The successful project would result in the provision of a unified enterprise view to employees and shareholders, in fact to all stakeholders.

The process, the result of a deliberate act of reflection, was constructed from answers to common-sense business questions: Why enterprise architecture (EA)? What are its economic drivers and benefits? What is the context of the technology? Basically, what are the requirements and what should the enterprise architecture deliver to the organisation?

At the initiation stage, the principle aims of the One Vodafone program were the standardisation of design and processes, reducing duplication, centralising certain functions, and sharing best practices.

The plans are now established and work streams are already well advanced, for instance, the successful roaming initiative that Vodafone announced recently, as well as the introduction of new service platform hosting centres, which have been built in Germany and Italy.

A few other developments within the Vodafone enterprise also helped pave the way to its overall enterprise architecture. These were: the group target architecture framework, including but not limited to, specifications of the service-delivery platform architecture; the integrated IP multimedia subsystem; intelligent packet core and services architecture; and the group IT architecture.

This paper will attempt to identify and summarise best practices in enterprise architecture, using the experiences and knowledge we have accumulated throughout the duration of these initiatives.

The narrative is based around a post-analysis of the existing experience at Vodafone and will follow the entire EA development process, recommending best practices at each phase. Practices are shown in a rather imperative manner, illustrated by a sample practice application of our own.

Enterprise architecture: The problem and the solution

A combination of increasing market pressure and years of patching and point solutions has seen many enterprise systems grow somewhat organically. What we are often left with is similar to the pieces of a complex puzzle, which we have to fit together to operate efficiently. But how does the puzzle enterprise operate in a predictive manner? How do you make sure that its business objectives are achieved across siloed solutions? In short, how do all the components of the puzzle enterprise fit together?

Increasing technological complexity, a daily rise in the amount of information we handle, and the ever quickening pace of change are expected to challenge the very existence of many enterprises in the next few years. One prediction is that EA will offer the enterprise the edge that it needs in the race for survival over the next decade. But, what is EA and, for that matter, what is architecture?

EA is the organisation of the enterprise and its blueprint for change, road mapping, product design, business modelling comprehension, and organisational evolution. In simple terms, EA shows how the enterprise operates.

We are all familiar with processes and programs such as EA, IT, service-oriented architecture (SOA), enterprise service bus (ESB), web services, distributed component architecture, and business-process management (BPM). But, how are they all related to each other? Indeed, are they related at all?

Enterprise architecture is often associated with SOA or IT architecture. But, the scope of EA can be wider than that of SOA or indeed IT, as it may encompass non-service oriented manual or mechanical processes. An SOA paradigm may be applied to the whole enterprise, not only to the IT infrastructure – eg, a “send bill” service may be implemented by a third party paper process with well-defined interfaces.

Why enterprise architecture?

As we discovered, this will no doubt be the most repeated question during the development process; asked by senior management, by stakeholders, by everybody. In response, business drivers must be explored.

Business drivers for an enterprise architecture

Business alignment with the IT and mobile infrastructure – thus enabling the business control of the enterprise, including the change and investment process;
Due to the current state of organic growth and patching, there is a growing need for enterprise simplification and integration of silo point solutions applications;
Increasing customer expectations for quality and worldwide competition, manifesting in rapidly reduced lifecycles and time to market, require an agile enterprise, prepared to change, evolve and deliver faster and better. In the dotcom era, a web year lasted three months.

The drive for implementation of quality frameworks such as Six Sigma and the Capability Maturity Model (CMM) has combined with recent requirements to adopt new regulations and auditing procedures. Legislation such as Sarbanes-Oxley and Basel II demands a structured, well understood, controllable and predictable business-process architecture. This should be accompanied by proper document and content management systems, all in the scope of an enterprise architecture. In the US, EA is already mandated within the Clinger-Cohen Act of 1996.

As an enterprise comprising at least 27 operating companies in various countries and continents, Vodafone’s main drivers were: to exploit synergies; reduce duplication; centralise and align processes, programmes, practices, applications, platforms and supplier – all using a single enterprise blueprint.

The benefits of enterprise architecture

According to John Zachman, the brains behind the Zachman Framework for Enterprise Architecture and Information Systems Architecture, EA provides “business alignment to IT, integration, response to change, and reduced time to market”.

It also allows for the treatment of all assets and projects as an enterprise portfolio, with dependencies and synergies accounted and planned for. The EA blueprint, or even model, will support a faster decision-making process and will enhance long-term investment planning.

Ultimately EA promises a competitive advantage by enabling faster product delivery at lower costs.

The return on enterprise architecture

Assuming there is a percentage ‘p’ in cost saving, and ‘p1’ is the potential for more revenue (reduced time to market and increased customer satisfaction) in the architecture compared to the no-architecture baseline case, a proposed indicator for the return on enterprise architecture (RoEA) will be:

Defining the EA development mission

An EA mission statement will capture, for all audiences, the essence of the deliveries development goals. EA should deliver an integrated blueprint of all business domains showing:

A context diagram illustrating the boundaries/scope of the enterprise and its stakeholders;
Diagrams of domain components with internal and external interconnections;
Stakeholder use cases and product delivery workflows mapped across components;
Answers to the ‘six illustrious questions’.

The EA blueprint should describe the enterprise in a hierarchical manner, cascading down from business objectives and enabling drill down to logical and technology-level architecture, to represent each stakeholder’s specific interest and views.

Ideally, EA should be able to show all areas of the enterprise operating at capacity, high costs or bottlenecks and, not least, should allow for simulation, change-impact assessment and business modelling.

What should be in place prior to initiation?

Underline the business objectives and model all stakeholder requirements. Also, establish EA deliveries up front or the outcome may be a long and heavy document, simply not fit for the purpose.

Define an architecture framework

This will be the backbone of the entire process. Select layers that you will be looking at, along with the principles that will guide the specification of the target enterprise architecture. The framework should be a structure describing the enterprise de-composition tree, from all architectural levels and from all views.

The framework itself should not define the component architectures, but join them, while showing component placeholders. It will usually look like a contents page, a mind map or a document tree, with the relevant component architectures hooking onto the framework. It enforces the specific system views and principles that consistently apply to all system components.

You may choose a domain-specific process architecture framework, such as eTOM (enhanced Telecommunications Operations Model), designed for the mobile telecommunications domain. Or you could, instead, adopt a more generic model (like Zachman’s) to specify architectural levels.

Determine architectural layers and views

For instance, business/conceptual, systems/logical, technology/physical. And, specify the initial set of architectural views/aspects: data architecture, security, disaster-recovery-architecture views, geographical and organisational views, customer care, operation-management views and, in the case of mobile telecoms, user and control planes, provisioning and charging views.

Establish your architectural and design principles:

Specify modular components for minimal coupling (decoupling principle) – a system function should be specified once in a single component/service;
Define components interfaces hiding implementation (hiding) – achieves separation of concerns and a technology agnostic component/service;
Use hierarchical design (decomposition) – components should be assembled in layers, within sub-systems. Logical processes in the business layer should be mapped to services in the systems layer and to physical platforms in the technology layer;
Use location agnostic, distributed design – interconnect services to an ESB or web-services protocols;
Design for non-functional capabilities – performance, availability and scalability;
Design security in – assess threats, probability and impacts and specify security policy. Assess intrusion points, design security zones accordingly and specify, for each zone, security, controls, access roles and access control lists. Use hardening, firewalling, layer 4-7 inspection equipment;
Design products to support roadmap, test and lifecycle – deployment, upgrade, retiring and recycling.

Choose an enterprise-architecture tool

An EA tool should document the whole process and store all artefacts from the beginning. A repository is essential for the documentation and re-use of EA artefacts.

The tool should support business-processes modelling and frameworks like Zachman or eTOM, to allow navigation of the architecture model, rendering on the web and intranet the ability to change control, support requirements tracing and control, and storage of artefacts as objectives and organisational information.

It should be able to store both current, as is, and visionary target architecture. A good tool will also support the ‘what if’ analysis of proposed changes, link to and integrate with other existing solutions and databases, and include features that comply with regulatory legislation.

Specify a design strategy

A recommended practice is: Bottom-up, document as is; top-down, design to be; and then, in the middle stages, use an SOA paradigm for integration of bottom-up and top-down systems.

Top-down modelling supports the development of the to be architecture over business processes, starting from the value chain and built on the architecture framework;
A bottom-up approach would consist of documenting the as is architecture and re-engineering legacy processes over a distribution middleware (ESB for instance);
An SOA in the middle approach would support the integration by modelling business processes (top-down) on business services obtained by encapsulation of legacy applications (bottom-up).

SOA can be built on an ESB, wrapping legacy applications, deploying business process engines and rules for orchestration, and employing ESB horizontal services eg, reliable transport, security, transactions, service-lifecycle management and service-level agreements. SOA can be built on and should interwork with web services.

Outline an implementation strategy

Assemble a top-level governance and enterprise-architecture team with a knowledge of: business strategy and objectives; your own business processes; BPM; IT infrastructure; legacy applications (domain architects); enterprise architecture frameworks; and, not least, SOA, web services and ESB technologies.

The team should be able to communicate, influence, negotiate, motivate, facilitate and inspire. In other words, get the human interaction right.

Name a governing function and build an EA group

This will control and enforce the overall cross-domain architecture design and implementation. The group will maintain and document the architecture, distribute reference architecture to suppliers (for compliance) and specify organisational change to match the enterprise blueprint. The governing function should include members of the management board. The EA architecture team will define the enterprise-architecture framework, layers, views and principles.

Select specific business-domain architect teams

These teams can design their own architecture within domain boundaries, providing the same system views, specified across all domains. They can interconnect their architectures at defined reference points and observe the common architectural principles.

Formulate critical success factors

The scope of EA should span the whole enterprise, not just IT;
Leverage existing applications and infrastructure;
Work with suppliers to transform applications into services;
Sell, not tell, by offering participation to all stakeholders. Obtain management commitment by building the business case for architecture;
Manage early cultural and organisational changes.

The execution stage

Once the process, drivers, business case, business requirements, framework, tool, and design and implementation strategies have been established, the starting point of the architecture needs to be assessed and documented. The to be architecture should be sketched at a reasonable level of detail and a migration path planned. At this point, the EA development can be executed.

Prioritise deliveries and iterate, using the 80/20 rule (80 per cent functionality with 20 per cent effort). Think of a spiral, iterative process.

Strategies to achieve best practices

Embed best practices in your organisation’s principles and policies for every development process and methodology, to ensure that it is an integral part of the enterprise framework. Document the EA process and enforce it, using the enterprise architecture tool.

Enterprise architecture is a continuous process of improvement, adaptation and managing the gap between as-is and to-be business objectives, which will be moving faster than your actual enterprise development. The most important thing to remember is that EA requires and imposes long-term planning.

Adrian Grigoriu is senior manager, emerging technologies at Vodafone UK.