How to bridge the gaps between business, IT and networks
To gain the agility required in the digital age, operators benefit from adopting a digital telco approach that transforms both the front and back ends of their business. The application of enterprise architecture (EA) principles provides excellent support in this work, leading to six key steps that help operators bridge the gaps between business, IT and networks, and thereby secure an effective transformation.
Telecom markets are increasingly driven by consumer demands for a better user experience, value-added digital services and competitive pricing. In this fast-changing landscape, business agility and flexibility are essential. A digital telco approach leads to a business and operating model that provides the agility required to manage the entire digital ecosystem. Operators can use it to create digital services and respond to consumer demands more efficiently.
Successful transition to a digital telco approach requires an agile and structured methodology. Industry-standard enterprise architecture (EA) principles bridge the gaps between business, IT and networks, making them an ideal choice for this purpose. They allow an organization to take a holistic view of its components and can be used to identify and analyze the key dimensions of a solution that is needed to deliver a desired business outcome. As a result, EA is relevant to the development of the whole enterprise – from business strategy, models and processes, to information systems and technical infrastructure.
The gap-bridging capability that EA provides is essential to succeeding in the transformation of both the front end of the operator's business, which faces both customers and partners, and the back end, which enables business capabilities.
Transforming the front end of an operator's business results in:
- The enablement of innovative digital services with shorter time-to-market and with higher quality, flexibility, automation, simplicity and experience for users and partners
- The digitalization of user and partner channels
Transforming the back end of the operator's business results in:
- Operational efficiencies through process automation and simplification
- Reduced complexity through a catalog-centric and component-based service oriented architecture that uses real-time interactions between IT and networks
- Reduced capex and improved business agility and flexibility through network functions virtualization (NFV), network programmability and cloud infrastructure
By establishing an EA practice as a central planning capability and an ongoing program with a solid foundation and tool to support it, an operator will be able to:
- Enhance decision-making by gaining a holistic view of its business and a detailed understanding of its EA artefacts and their relationships
- Effectively manage change by enabling impact analysis of affected artefacts and eliminating discovery time and effort
- Plan evolution from as-is to desired architectures by providing guiding principles for planning and selection of transition states
- Better align IT to business by demonstrating alignment between IT initiatives and business objectives, and expressing architecture work in terms of business outcomes and capabilities
- Shorten time-to-market by promoting re-use of patterns and packaged building blocks
- Decide the priority and pace of development of new system components. An EA approach can help make decisions about architectural methods, such as where to pick microservices design or central-orchestration, and when to use DevOps or traditional development streams
As shown in Figure 1, EA methodology is comprised of a governance framework, a work method, a meta model and a tool, and is supported by reference models.
The governance framework manages and controls EA enterprise-wide, ensuring that processes are in place to secure the best possible compliance with the target architecture. Governance is achieved by setting up the right EA team structure to operate its EA work method, and by formalizing the team's interactions with the EA stakeholders.
The work method is the process followed to plan and develop architecture, identify solutions and govern their implementation. It is also the process where all the relevant architecture artefacts are gathered and linked to describe the state of an organization from both a business and a technology perspective.
The meta model defines the description of the architecture artefacts in a structured way. It formalizes the relationships between the artefacts to ensure impact analysis and to provide traceability between the different parts of the architecture. A meta model acts as a blueprint for the EA tool. Thus, folder and element hierarchy are designed based on the meta model. Depending on the tool capability, technical necessities may cause some deviation from the meta model while designing elements or folders.
The tool provides a wide range of modeling capabilities, reporting and publishing functionalities, and effective, easy-to-use interfaces to define, store and link architectural artefacts. The output of the EA work method is normally stored in the EA tool, the modeling structure of which is customized according to the EA meta-model.
The reference models are frameworks, best practices and reference architectures developed by external parties that can be applied to develop target architectures. Examples include TMForum Frameworx, ITIL and TOGAF Foundation Architecture.
Translating business requirements to achievable operational and technical capabilities requires an end-to-end approach and agile ways of working in cross-functional teams. This approach ensures that business benefits are realized quickly enough to keep up with market dynamics and consumer expectations.
We recommend that operators follow six steps to bridge the gap between business, IT and networks. Each step is a practical result of applying EA principles to the development of the whole enterprise.
The steps are:
- innovate business models
- redefine operating models
- define EA strategy and IT planning
- realize business benefits
- use EA reference models and tools
- realize end-to-end solutions
1. Innovate business models
While business model innovation in the back end is increasingly critical for operators, the execution of front-end transformation is essential to their ability to realize their value propositions. Defining business strategic goals and implementing the required business enterprise models is necessary to set the priorities for the scope of the required transformation of both the front-end and back-end capabilities. Alexander Osterwalder's Business Model Canvas, as shown in Figure 2, illustrates the various aspects of the front-end and back end transformations, as well as their connection to the value proposition and finance.
Consider this value proposition, for example: "As a market-leading digital telco, we will offer the market's most attractive portfolio of digital services to retail and enterprise users, with a competitive price and the market's best perceived user experience." Realizing this proposition will require that the operator implements business capabilities in both the front and the back end.
The front-end transformation will need to address revenue and value streams. In this example, the focus will be on digitalization and omni-channel access (as the interaction channels); big data analytics and business intelligence to gain user insights from consumers and retail and enterprise users (as the customer segments); and self-service and social media networking (as the customer relationships).
The back-end transformation must address cost structure. In this example, it would involve the catalog, convergent charging and billing (as the core capabilities); SDN, NFV and cloud infrastructure (as the infrastructure capabilities); real-time automation and simplification (as the activities); and digital service partnerships and communication service partnerships (as the partners).
2. Redefine operating models
It is not uncommon that front-end and back-end transformation leads an operator to rethink its entire operating model since it contains high-level practical plans for how to run daily business operations. All dimensions of the operating model – including KPIs, technology, processes, people, organization, partners and alliances – will be impacted by the transformation and will need to be redefined to handle digital services, manage consumer experiences and function in the new digital ecosystem.
Figure 3 shows the components of a target operating model, namely: KPIs, technology, processes, people management, organization, and partners and alliances.
For KPIs, the front-end and back-end transformation will make it necessary to introduce goals and metrics that combine top-line growth, net promoter score and margin. These KPIs will drive the activities and measure the success.
In the technology area, the transformation will require the creation of an informationcentric and service-oriented architecture of applications to increase agility and decrease the cost of integrations. It will also be necessary to enable flexible infrastructure that is ready for the digital services landscape, using cloud, NFV and software-defined networking technologies.
In terms of processes, the transformation will require the automation and simplification of end-to-end process flows, as well as an increase in the level of self-service in the front end. The level of automation and self-organized networking in the back end will also need to be improved.
People management will be affected by the need to establish a user experience-centric culture, while the organization will be impacted by the establishment of new organizational structures that support agile ways of working in cross-functional teams.
Finally, in the area of partners and alliances, the transformation will require a shift to a collaborative approach with a new ecosystem of partners/enterprises and over-the-top (OTT) players.
3. Define EA strategy and IT planning
For an operator to realize its redefined operating model, it is necessary to define an EA strategy and do the IT planning (including the target architecture) through the practice of a holistic assessment approach. Figure 4 illustrates the EA assessment methodology. This approach aligns an organization's strategy, business, information systems and technology, and aims to define the future vision, target state and planning steps by performing activities in six phases: Scope, Discover, Diagnose, Target, Roadmap and Propose.
The focus and scope of the EA assessment is defined in the Scope phase. The Discover phase involves assessing and evaluating the current state of the organization and its EA, including strategy capabilities, business processes and information systems, as well as current and planned projects. In the Diagnose phase, the focus is on identifying pain points and gaps, defining process heat maps, completing an information systems health assessment, presenting first findings and recommending quick wins.
The Target phase involves the creation of a target state EA to support the required business capabilities in the form of business process recommendations and an information systems architecture end game. During the Roadmap phase, the project team creates a strategic transition plan and roadmap to achieve the future state through a set of transformation activities and defined transition architectures. Finally, one or more holistic transformation proposals are created in the Propose phase.
4. Realize business benefits
The realization of business benefits is a fundamental objective of EA principles. This process is driven by the business capabilities that have been identified as requirements – for example, by an operator that has decided to apply a digital telco approach.
A business benefit is defined as the result of an action or decision that contributes to meeting one or more business objectives. It is a measurable outcome from an action, investment, project, resource or technology, and represents a central element in strategic planning and building business cases. Business benefits can be categorized into four types: revenue, operational, customer experience management and business efficiency benefits. Realizing business benefits is a continuous improvement process that requires constant interactions with business stakeholders.
Figure 5 illustrates the activities that are performed during a typical EA exercise. High-level objectives are broken down into tangible business capabilities, which are then used to create a target architecture and roadmap that will drive initiatives that produce real business benefits (or results). Depending on the background and the context, the sequence of the activities might shift, or the result might be obtained from another exercise. In some cases, some of the activities may be interchangeable or skippable.
Strategic objectives and results
The strategic objectives are what motivate the digital transformation and drive the strategic programs that are conceived by it. An expected result is connected to each objective. The transformation programs must contribute to one or more results at the end of the process. While not all objectives are related to IT, the fulfillment of most business needs are enabled by IT functions. The results are calculated after a predetermined period of time. The leadership assesses how much the programs contribute to the objectives based on the results before deciding on the next actions. Strategic objectives can be categorized in the same way that benefits are.
Capture business capability requirements
Based on its strategic objectives, the operator should capture and prioritize critical business capability requirements. One example could be the business capability requirements of efficiently and effectively provisioning virtual network functions and services.
Ericsson has created a comprehensive set of critical digital telco business capabilities that makes it possible to carry out kick-off planning activities quickly. The hundreds of capabilities included in it have been defined and mapped into the four previously mentioned benefit categories (that is, revenue, operational, customer experience management and business efficiency benefits).
Figure 6 shows a sample digital telco business capability card. Its purpose is to aid in the preparation and prioritization of a capability subset that will point out which processes and systems need to be analyzed and focused on during the assessment study.
Analyze end-to-end business process impacts
It is important that an operator analyzes the business processes that will be impacted by the new business capability from an end-to-end perspective, by identifying pain points and defining KPIs to measure business process performance. The aim is to simplify and automate processes, and to reduce the number of organizational handovers.
For example, in a plan-to-provision scenario, it is necessary to analyze the impact on the end-to-end process created by managing virtual network functions. There is also a requirement to define KPIs, identify pain points and perform heat mapping to identify potential candidates for simplification and automation.
Define customer journeys
The operator has to expand its reach to the customers. Doing so requires new touch points that provide customers with more empowerment and more flexibility, of which traditional channels don't provide. The main goal of this approach is to create an intuitive, easy-to-use, customer-centric system that runs without any assistance. Customer interactions and activities are represented in a holistic way using customer journey maps with the help of concepts such as storyline, persona and sentiment.
Drill down to business processes and design use cases
The operator needs to drill down to end-to-end processes to further isolate critical steps. This involves illustrating and analyzing use cases in activity and sequence diagrams to identify the expectations on each logical application building block's (ABB) capabilities and integrations.
In a plan to provision example, the process should be drilled down to individual configurations and deployment use cases to analyze the detailed requirements for configurations of, and integrations between, logical ABBs to support the use cases.
Detail user experience and omnichannel interactions
Embracing customers in more personal and intuitive ways requires novel methods. Traditional design methods such as processes and use cases do not comply with customer centricity. It is not possible to easily create a different experience for different personas, feelings and access points. Ideally, the user interfaces for a variety of devices are set to be modeled during this activity, including conceptual design, wireframes and mockups. Experience design usually includes test activities, such as usability testing and closed-group end user testing, and at later stages A-B testing may also be used.
Define target architecture
The operator should analyze and define the ICT and network ABB capabilities required to realize the prioritized business capabilities through the use cases. This includes an audit of the available capabilities of legacy applications and a clear definition of the application capability gap per ABB. There is also a need to identify the key information entities and information sources for the target architecture design, and to define a high-level logical information model including a CRUD (create, read, use, delete) matrix that shows ownership and dependencies.
The most cost-efficient target architecture design of the ABB landscape should be created following architectural principles such as a catalog-centric approach and service-oriented architecture. In a plan-to-provision example, the functional capabilities of the legacy applications in the network planning, optimization and configuration domains should be benchmarked against the requirements of the new ABB capabilities for managing virtual network functions. The key information entities and information sources should be identified and analyzed for the target architecture design. Based on the gaps identified, a target architecture that includes all required capabilities can be defined.
Define a solution roadmap and a deployment model
The operator needs to define a roadmap for solution realization, including recommended software packages and migration strategies. In the example shown in Figure 6, the new ABB requirements would be mapped to a capability evolution of the legacy applications that are deployed. Alternatively, a roadmap for a side-by-side replacement with a fit-forpurpose commercial solution suite should be proposed that fulfills the requirements of managing the resource lifecycle of virtual and non-virtual network functions.
The real-life situation may be different for some operators, depending on their needs and market situation. In some cases, the business requirements may lead an operator to choose a different path from integrating commercial software. In these situations, the roadmap can contain different approaches, such as application development and modernization (ADM) services. A continuous development/continuous integration (CD-CI) approach is well suited to the development of customer journeys and user interfaces, as they require more speed and agility every day.
Realize solution projects
This phase is not part of the planning activity but rather, the actual execution of the plans that were made in the previous phases. Each identified and outlined strategic program or tactical project will enable some business capabilities, which will contribute the overall results that are linked to strategic objectives. As a result, the success of the overall activity will be measurable.
Application Building Blocks
An Application Building Block (ABB) is a well-defined set of application functions developed to support business processes and associated data. An ABB represents a coarse-grained functional component of an application that should in most instances be able to run on its own. This means that an ABB is a self-contained piece of software that may be purchased in the open market individually or as part of a much larger suite of applications. In addition, a COTS product can correspond to a single ABB or to a set of ABBs.
5. Use EA reference models and tools
An operator's operating model is described in hundreds of different EA artefacts – as end-to-end processes, use cases, and application and information entities, all with dependencies and interrelations. Documenting these in ordinary word processing and drawing tools is not sufficient to manage change effectively, improve time to market or achieve operational efficiency. In fact, EA artefacts that are documented in this way often end up on a shelf, rather than being used for operations or for driving change.
Driving change that effectively increases speed and flexibility requires the active use of an EA tool that streamlines documentation, facilitates communication and enables continuous improvement. Such a tool makes it possible to manage new business requirements with shorter time to market and greater operational efficiency.
By helping operators to clearly document EA artefacts and their relationships to other artefacts in a structured and consistent way, an EA tool helps operators realize new business benefits with reduced time to market through enabling a faster and more efficient impact analysis of new business requirements. Further, the consistent notation, layering and terminology of EA artefacts facilitates improved communication between operators and their stakeholders and business partners. Finally, an EA tool helps operators achieve continuous improvement by establishing a unique repository that enables them to understand and manage impacts on COTS realizations during change, thereby avoiding unwanted effects and business-impacting mistakes when executing changes.
Ericsson has developed a framework and methodology that we use to deliver transformation projects according to the requirements of EA practice that we call Ericsson Value Architecture (EVA). EVA is pre-populated with ready-to-use artifacts and elements, and includes design time features to increase the efficiency and effectiveness of the design process. Users can easily access EVA from anywhere in the world to kick-start their work. With EVA, users can model use cases and system architecture, as well as processes and customer journeys. EVA also provides utilities such as requirements management, reporting and document generation.
6. Realize end-to-end solutions
End-to-end solutions should be based on a transformation roadmap and two practical considerations: best-of-suite versus best-of-breed and side-by-side versus step-by-step.
Best-of-suite versus best-of-breed
The traditional best-of-breed solution approach – in which operators cherry pick different vendor software products and stitch them together with major integration efforts between multiple systems, data sources, information models and customized architectures and solutions – is no longer recommended. It simply takes too much time, effort and expense for an operator to develop, manage and evolve custom-built solutions and OSS/BSS architectures.
What operators require are OSS/BSS solutions that are industrialized, supported and shared with other actors in the marketplace to the largest extent possible. Instead of a best-of-breed solution, operators need a best-of suite approach that meets evolved OSS/ BSS demands, improves time to market, reduces TCO and simplifies solution evolution.By using horizontal software platforms and supported solutions, the operator can also reduce overall transformation complexity. When going for a best-of-suite approach, a strategy should be in place to avoid vendor lock-in and a one size-fits-all approach.
Side-by-side versus step-by-step
A step-by-step evolution – in which the existing capabilities of an operator's legacy OSS/ BSS landscape are complemented with additional application capabilities for a specific and clearly defined purpose – can be the right approach in some cases. However, transformation of the back-end and front end architectures to fully support the application capabilities required by a redefined operating model requires a more pervasive change that is best realized using a side-by-side migration strategy.
With a side-by-side strategy, standard components and a modern EA that incorporates clear views about data separation are used to build a catalog driven architecture based on common master data repositories. This approach focuses on key data entities such as users, products and resources. A sound data migration strategy that includes the introduction and maintenance of master data repositories is an important component of a side-by-side strategy.
A digital telco approach is the best way for operators to achieve the agility required to thrive in the digital age. However, this approach requires a transformation of both the front end and back end of an operator's business. Since EA is concerned with planning the development of a whole enterprise, including its business processes, information systems and technical infrastructure, it presents operators with a great opportunity to manage this transformation, by bridging the gaps between business, IT and networks.
We recommend that operators apply EA principles to steer their decision making toward the evolution of the future-state architecture. They should establish an EA practice as a central planning capability, and as an ongoing program with a solid foundation and tool to support it.
We have identified six steps that operators should follow to bridge the gaps between business, IT and networks. Each step is a practical result of applying EA principles to the development of the whole enterprise. In summary, the six steps are as follows:
- Innovate business models based on the enterprise business strategy to respond to consumer demands in digital services. This will set the right scope of priorities for the front-end and back-end transformations
- Redefine the operating model to handle digital services, manage holistic consumer experiences, and secure both operational excellence and the agility to manage the full digital ecosystem
- Define an EA strategy and IT planning by applying a holistic assessment model based on the principles of scoping, discovery, diagnosis, targeting, roadmap and proposing
- Realize business benefits as a continuous improvement process that builds on constant interactions with business stakeholders
- Use EA reference models and tools to manage new business requirements with shorter time to market and to improve the quality of changes
- Realize end-to-end solutions by building a transformation roadmap and applying a side-by-side migration strategy using best-of-suite solutions
ABB - Application Building Block
COTS - Commercial Off-The-Shelf
CRUD - Create, Read, Use, Delete
EA - Enterprise Architecture
NFV - Network Functions Virtualization
Yusuf Mithat Cengeloglu was the main contributor to the updated version of this
white paper published in 2018.
Yusuf Mithat Cengeloglu
Yusuf Mithat Cengeloglu joined Ericsson in 2009 and currently works as an enterprise architect within Ericsson's Global Digital Transformation Practice, where he focuses on business and systems architecture, digital transformation and software development. He has also been involved in the creation of practical methodologies and the industrialization of assets. Yusuf has extensive experience helping operators in the Middle East, Europe and North America acquire the capabilities they need to reach their digital targets. He holds a B.Sc. in Aeronautics and Astronautics and an M.Sc. in Satellite Communications and Remote Sensing from Istanbul Technical University.