IT is an integral part in businesses of today. It is a critical component in a majority of business processes, from customer interaction and support processes, to business infrastructure and product development. IT becomes increasingly more important as digitalisation intensifies. The ability to manage technology in this ever-changing environment becomes a driver for competitive advantage. IT organisations need to manage an integrated, diverse and complex portfolio of technologies delivered both internally and via external partners. Complexity and the rapid pace of technological change create a need for a disciplined, structured and business-aligned technology integration strategy.
IT organisations are faced with an increased pressure to deliver innovation, either driven by customer requirements or through proactive, technology-driven business development, as shown in picture 1. This pressure is prevalent, to various degrees, across a wide range of industries and IT organisations are struggling to keep up. In this whitepaper, 3gamma and Scienta, outline a model for using the concept of value disciplines to define integration architectures and technology strategies to support different business requirements and expectations. As a conclusion, a high-level approach for transitioning to a target model is presented.
Using value disciplines as a blueprint for business and IT alignment
In essence, there are three paths to market leadership. Companies can become market leaders by excelling in either operational excellence, customer intimacy or product leadership. These paths, or value disciplines, align with three generic core processes: business infra-structure process, the customer relationship process and the product innovation process.
The economics, rules of competition and culture, differ between the value disciplines, see table 1, for companies to excel in any of the core processes, focus is key. Rather than being good enough in all three processes, companies should direct investments and focus on one of these core processes. It follows that IT’s role is different in each setting; supporting standardised, predictable, and highly efficient (business) operations is different from fostering creative innovation or customer intimacy. Even though this may appear obvious, many IT organisations are oriented toward operational excellence.
Drawing on 3gamma’s and Scienta’s experience, many IT organisations focused on internal efficiency during the last few decades, standardisation and cost savings were the focus for countless IT initiatives. IT organisations became centre of excellences, providing standardised generic services. IT costs were cut and processes optimised. IT almost seemed to exist for IT’s own sake. Even worse, it created organisational inertia, where IT organisations became slow to adapt and unable to innovate. Ironically, IT itself became an obstacle for the digitalisation of business. Keeping pace with technological advancements, adopting new innovations, and aligning them with the business strategy became increasingly difficult.
In a digital economy, IT needs to continuously and rapidly acquire new, advanced capabilities in order to align with an ever-changing business. This impacts on internal processes, operational models, IT sourcing strategies and how companies manage technology. Specifically, integration architecture has to be a top priority for IT managers. Essentially, it is an enabler of a company’s value discipline. Integration architecture can, if managed and implemented wisely, contribute to drive standardisation and cost reductions, customisation and specialisation, and/or innovation. As shown in table 2, the organisational impact, the capabilities needed, how technology is managed, and the key considerations for IT management differ between the value disciplines.
Integration architectures for operational excellence
Operational excellence is about achieving standardised, cost-effective and predictable products and services. Companies following this value discipline are not unaffected by digitalisation and are non-dependant on IT innovation. However, it means that the application of IT technology within the company is different, it is a supporting the capability to achieve the overall goal of operational excellence. IT needs to adhere to a pre-de-fined, controlled formula. Typically, an IT organisation supporting an operational excellence focuses on:
- Limited set and standardised set of services
- High expertise in defined services
- Limited to moderate frequency of change through a pre-defined release calendar
- Cost-efficient, predictable, high-volume operations through standardised IT processes
- Continuous improvements to existing services
- Consolidated IT environment and/or a limited set of standardised applications
- Often a single-vendor outsourcing or a layered (infrastructure/application maintenance) outsourcing with few service providers
Key capabilities include: process management, service introduction, service delivery and supplier management. Starting from a technology point of view, critical success factors are standardisation and keeping applications and infrastructure as homogenous and ’off the shelf‘ as possible. The simplest and most cost-effective way of integrating such Commercial Off-the-shelf (COTS) systems – cloud or on premises – is by applying classic Enterprise Application Integration (EAI). The advantage is, that very little customisation is required to the systems, centralising most of the logic and custom code in the broker. This is then deployed in a hub-and-spoke type topology (see figure 2). Centralisation requires that the organisation build core competence in integration infrastructure and take responsibility for orchestrating business processes and implementing core business logic.
Different broker systems can be employed, most commonly a high-end integration platform with support for business activity monitoring and process management, these brokers are often classified as enterprise service ‘buses’. Nevertheless, given their central role in the architecture they become mission-critical business applications, rather than pure integration infrastructures. Ergo, IT organisations must have skilled personnel with deep business knowledge, as they become a critical factor in the IT maintenance and development process. This should be considered when developing the IT sourcing strategy.
Managing technology in this context, is about managing and aligning the strategic vendors’ roadmaps (the applications illustrated in figure 2) with the internal need for business development. The integration architecture should act as the intermediary that creates the customisation required to meet business requirements and create operational excellence. The role of IT strategists and IT architects, is to work closely with service managers to cater for the introduction of new standard functionality into production. IT sourcing is critical and long-term partnerships with a few select service providers should be considered, as reduction of transaction costs relating to sourcing is an important factor. The role of the contract is to govern and control deliveries with clearly articulated service level agreements and predicable costs.
Integration architectures for customer intimacy
Customer intimacy is about interacting with the customer to deliver customised, broad solutions to create high-value and long-time relationships with customers. Customer intimacy builds on the ability to understand and respond to customer requirements. Typically, an IT organisation supporting customer intimacy focuses on:
- A wide range of services
- A flexible and agile delivery organisation, typically controlled by product owners in the business organisation
- A moderate to high frequency of changes within the IT environment/IT services
- A diverse IT environment, often with significant customisations in applications or as complementary applications
- A multi-sourcing environment with several vendors or a significant in-house IT footprint
Key capabilities include: strategic and operational business relationships, project portfolio management, program and project management, business development and solution architecture; from a technology point of view, the ability to customise is critical. It is imperative to cater for best of breed solutions and integration of these with standard packaged solutions and custom development.
The importance of IT depends on industrial context, for example, in a manufacturing company IT is likely to be focused on integration of COTS with limited customisation, both in the integration and the systems themselves. In this setting, the technology strategy share a number of traits with operational excellence. The competitive advantages will most likely lie in the way the organisation is involved with the customer, and the level of adaptability of each system to meet each customer’s specific requirements. The customisation typically originates from the complementary services offered; for service-based industries, where the business is driven by providing services that are tailored to the customer needs, a much more specialised IT portfolio is required to gain competitive advantage. Pure COTS may still be a good choice for certain parts, but it is likely that custom-developed applications or significant adaptations are required to support the business.
One way to manage the inherent complexity arising from customisation, is to employ domain-driven design (DDD). Clearly defined domains and service-orientation can be used to enforce a loosely coupled set of highly cohesive business services. The service boundaries should be viewed as logical, modelling all, both custom and commercial systems, into groups that match the business areas, e.g. sales, customer support, marketing, inventory, shipping, and billing. Each of these business areas, or services, can contain several systems and components from different layers, e.g. databases, middleware and front-end applications and their interaction with other services should be few andas loosely coupled as possible.
Ideally, each service should be able to deliver its business functions, neither needing data nor support from others. One way to achieve this is to distribute the data, letting each service own its own data and get all the reference data it needs from others when state changes occur. A service is hidden behind the bounded context as defined in DDD, an essential concept when designing a system of highly autonomous services aligned with the core business capabilities. By making the services as autonomous as possible, they can have individual life-cycles and therefore be better suited to meet ever-changing business requirements. This setup will, as opposed to the operational excellence case, have as little logic and functionality in-between the services as possible. Logic between services create coupling and reduces service autonomy. In this scenario, ’dumb pipes, smart endpoints‘ are required. Integrations should be purely technical, and preferably brokerless, thereby avoiding any leakage of business functionality across the service boundaries. The integration architecture should be based on messaging systems that simply route messages from one endpoint to another. Some choose to use web services or REST4, while others take it to the ultimately loosely-coupled approach and enforce event-based integrations only. Such an event-driven approach implies no request/response between services and any state changes are propagated as simple messages, similar to a finite state machine. Such an approach will require a high degree of maturity in the service design, but will at the same time make integration as simple as network routing.
The service-oriented approach will create a more manageable IT portfolio, which is aligned with the business organisation and its needs. The portfolio will also be highly adaptable to frequent business requirement changes, but it will require organisational changes to IT. Teams need to be built around the services and they need to take full ownership of the services’ systems, applications and business capabilities.
Managing technology, in this context, is about maintaining a clear view of the technology landscape and continuously managing the application life-cycle across all business processes. Maintaining an understanding of the applications and their underpinning infrastructure, including all integrations, is key to enabling customisation and controlling the cost and risk. Complexity, arising from both technology and the vendor portfolio, is inevitable and IT must be capable in managing it. The role of the outsourcing contract is to govern collaboration and additions/changes in a clearly defined way, underpinned by a set of goals and objectives that are shared between the customer and the vendor.
Integration architectures for product leadership
Product leadership is about delivering new and innovative product services to the market ahead of the competition. IT is often an integral part of the innovation and business development process6. Product leadership requires IT to be a proactive business driver. Typically, an IT organisation supporting product leadership focuses on:
- Limited set of high-end/strategic IT services
- Standard services for non-core business functions/processes
- Advanced capabilities within project portfolio management
- High frequency of change
- Autonomous, self-organising teams with ’good enough‘ processes
- Modularised IT architecture, solution components and systems
- Non-standardisation, both from a process/governance point of view and a service point of view
- A mix of multi-sourcing and in-house IT
Key capabilities include innovation, business development, enterprise/IT architecture, program and project management, solution architecture, IT development, and testing. Additionally, IT needs to scan the market for new competitive capabilities and technologies to incorporate into its portfolio to proactively define and execute on new business opportunities. For companies focusing on product leadership, a highly distributed service-oriented IT landscape is a necessity. Flexibility and parallelism are required to deliver new services and components without affecting ongoing operations. In this setting, service-orientation is mainly a top-level architecture and maps to a limited set of well-defined business areas. As for customer intimacy, each service will typically be broken-up into a large number of small and autonomous business components, each owning and running specific parts of the service’s responsibilities. While each service in the customer intimacy path may contain large COTS and small custom-made applications, this approach requires a more fragmented setup. Many refer to this approach as microservices. The idea is, that each service within a service is as small as possible in order to be able to create, change, and retire them quickly and with as little impact to existing components as possible.
Integration between each of these components may be done in different ways, both using request/response, shared state (e.g. session objects) and message-passing. As for top-level services, using events creates the least amount of coupling. However, this must be balanced with the need for composability of various components from different services in one or several business processes. In such situations, shared state is a good choice, e.g. by using UI composition, and sharing state using session cookies.
A highly fragmented and distributed IT landscape will raise the expectations on the IT organisation. Each team must take full ownership of the life-cycle of each service and its components, from initiation to retirement. In essence, this means that when employing a microservices architecture, DevOps7 is the preferred way to go in order to get safe, stable and cost-effective operations. Innovation, especially outside the boundaries of existing operations, requires dedicated teams.
Outside-in architectures would begin with the challenge of organizing IT resources across a large ecosystem of individual and institutional participants […] There won’t be any single control point from which the designers of such an architecture could mandate adoption of specific applications”.
Managing technology in this context, is about managing innovation. From an internal perspective, innovation is likely to occur through collaboration, cross-functional and dedicated teams with external partnerships/inputs. Innovation initiatives typically require an ad hoc organisational model and a well-defined learning and feedback process10. IT outsourcing requires special attention is this setting, as it cannot be focused on operational excellence. Innovation thrives from variety and experimentation, things that are not easily captured in a contract. The role of the contract is to outline the use of resources in the innovation process, be it technological development, sales or consulting. Innovation clauses in the contract that define upfront the expectations on innovation are contradictory to the logic of innovation, as it cannot easily be standardised through definition of predictable and repeatable processes. These type of clauses are suitable for continuous improvements, not innovation.
Taking a strategic approach to managing technology and integration to ensure business alignment
To address multifaceted business customers, IT needs to create a toolbox for meeting differentiated requirements. Integration management and technical architecture are at the heart of that toolbox:
- Improve time to market for new services by using information and functionality across applications and services and by operationalising processes for integration development, including providing supporting tools and processes
- Improve stability and robustness of business services through minimised operational dependencies between applications and integration technologies, e.g. queue management technologies and monitoring services
- Enable IT sourcing aligned with business objectives by decoupling sourcing objects, i.e. keep them separated to make it possible to align the sourcing model per object, rather than applying a one-size-fits-all approach
- Enable innovation and development within each sourcing object/functional area/business process in a flexible way. Integration can make it possible to rely on the functional roadmap of the business applications, rather than having to drive development internally.
- Optimise operational costs and reducing complexity across the application and infrastructure portfolio by implementing the right functionality in the right application and keeping applications ’as standardas possible’
- Enable scaling of individual services and defining specific service level agreements per service to meet new non-functional requirements, e.g. to manage monitoring in an internet of things context
Companies need an approach to managing technology that is aligned with IT’s strategic direction. The IT capabilities and the IT support needed by the business need to guide the IT architecture and integration strategy, as illustrated in figure 4.
The classic approach to integration management is to set-up an integration competence centre (ICC) as a centralised function or as a unit tasked with the design, development, maintenance, and operations of integrations and underpinning infrastructure. This function is in control of the majority of information exchanged between applications within the portfolio. This model fits very well with an operational excellence focus. It establishes clear control, robust delivery processes and a centralised body of knowledge to manage implemented business logic. It also aligns very well with a cost-focused outsourcing (economies of scale). It is however not suitable for neither customer intimacy nor product leadership.
In a customer intimacy setting, the technology management and integration are no longer about exerting control but rather to facilitate effective customisation/flexibility and to provide the necessary tools and processes to autonomous development teams. Any centralised function should be a small team focused on developing common assets than can be deployed within IT. Business logic will be implemented within the end-points by separate teams. The division of responsibilities between the central team and the distributed development teams should be done based on time to market requirements. The central team will also provide documentation services to maintain an overview of a complex, customised environment.
Product leadership is based on innovation. Central control, or even common processes and technologies, could be detrimental to IT’s innovation capabilities. Hence, there shouldn’t be any central unit/function governing and controlling integration. Technology management and integration should be guided by a set of principles that are created by and communicated across self-organising development teams. New ideas and thought leadership (note, not best practices) are disseminated through common forums. Communication of principles, coaching, and forums may be facilitated by a central function.
These blueprints for technology management and integration also give guidance for companies following an operational excellence strategy that strives to drive an innovation initiative. The innovation initiative cannot be forced to adhere to the well-honed IT delivery processes currently in operation. Exceptions are needed and a customised organisational model and integration architecture should be not only allowed, but encouraged. What got you here will not get you there.
Transitioning into a new approach to strategic integration management
The key to unlocking the value of integration, is understanding the company’s strategic focus (or, in some cases, focuses). Integration and the associated organisation are not for IT’s sake, it’s for the business’.
- Perform a gap analysis:
- Map each business process to one of the value disciplines (operational excellence, customer intimacy or product leadership), understand its dynamics and value drivers
- Assess the current baseline, understand IT’s ability to deliver according to the business requirements, preferably using a capability model and integration maturity assessment
- Analyse the trade-off needed between meeting all requirements and the cost of meeting these, choose a primary focus. The most critical focus from a holistic portfolio perspective needs to be defined
- Map the preferred position to the generic roles for integration (see figure 4) to define the primary purpose and ensure business alignment
- Define performance indicators for integration within the company, e.g. in the dimension discussed earlier – time to market, stability and/or cost
- Prioritise areas where nothing happens, even though where what happens is in conflict with the business direction in question. Create roadmap of initiatives
- Implement the IT architecture and integration using iterative methodologies, i.e. incremental value realisation, to avoid a big-bang approach. Measure continuously and provide feedback across the organisation, both to business customers and within IT
- Continuously improve the IT and integration architecture through feedback and learning mechanisms and by revisiting the assumptions for the design regularly (frequency depending on the frequency of business change)
Integration is an enabler of cost-effectiveness, flexibility, robustness and time to market. Technology management and integration are skills that directly impacts IT’s alignment with the business strategy. To deliver value the integration/technical architecture strategy needs to be aligned with the organisation/capabilities, processes and governance, as well as the sourcing setup. A key tool for achieving this alignment is integration and preferred integration patterns deployed within the environment.
About the authors
Jens Ekberg, Director and Head of Solutions at 3gamma Sweden. Jens’s focus on developing 3gamma Sweden’s offerings across IT strategy, IT sourcing lifecycle, IT legal advisory, IT risk and assurance, IT operational excellence and IT project management and delivery. Jens has significant experience working with integration architectu-re across several industries.
Trond Hjorteland, senior developer and IT architect at Scienta. Trond has significant experience from working with integration in a wide range of industries, with a special focus on modularisation, domain driven design and event-driven service orientation (EDA and SOA). Trond can be reached at email@example.com