Everything as a Service

9 years, 7 months ago

Service Factory 2.0

by

In July 1989 the Harvard Business Review published a seminal article by Chase and Garvin titled The Service Factory [1]. They argued that “The factory of the future is not a place where computers, robots, and flexible machines do the drudge work. . . the next generation, then, will compete by bundling services with products, anticipating and responding to a truly comprehensive range of customer needs.”

Since the publication some 25 years ago, much has happened to validate Messrs Chase and Garvin’s thesis. The world has manifestly transformed into a “service based world”. By some accounts the service sector grew to over 80% of the US economy by 2000. There are various implementations of the Service Factory concept; we might observe that the ubiquitous Call Centers represent a scalable, repeatable factory model. Similarly in the technology world services, or APIs, are a central part of many IT architectures, and some firms have adopted a service factory model by separating service and solution delivery.

But it must be said that for most enterprises there remains a significant gap between the business and software services. Over 25 years ago Chase and Garvin recognized this as an issue. They use the example of how 200 years ago horse-drawn carriages were mostly made by craftsmen, and the most successful carriage maker was invariably the most accommodating for the customer. But as mass production overtook craftsmanship customers came to value standardized, lower price more than higher price, personalized products. Gradually manufacturing became separated from pre and post-sale customer facing activities. In recent years in some industry sectors, there has been a noticeable reversal of this trend, and mass customization is widely practiced. However in many industries, notwithstanding Agile methods focus on customer involvement, the design of business services remains a discrete activity from the architecture and design of IT services.

This is starting to change. The Mobile revolution and the Internet of Things will inevitably cause a convergence of business and software services. I have described this as “turning the business inside out”. In future it will be a very rare business service that isn’t delivered by a software service, at least as an option or complement. It’s a racing certainty that Call Centers and other conventional service delivery models are going to go the same way as Telephone Exchanges, Typing Pools and Airline Reservations Departments! In this fast emerging world, “everything is a service”. And this will have a profound impact on the shape of the Service Factory of tomorrow.

The Service Factory 2.0 will be a software factory separate from solution delivery projects. As discussed some firms already employ this organizing model in order to architect and design services to standardize core business information and rules for use in many processes.

The software factory concept has been in use for some time, particularly in conjunction with the Product Line concept, where common components are delivered using a framework of tools, repeatable processes and patterns, that are reused in solutions supporting the Product Line. The Service Factory 2.0 is a specialization of the software factory, with a framework that is specific to services. However the most effective service factory will also be a “business service” delivery model in which the life cycle of the business, software and IT service perspectives are integrated.

We can anticipate a number of critical innovations that will enable the Service Factory 2.0:

1. Everything is a Service All business capabilities are delivered as modular software services which are integral to the holistic business service offering.
2. Automated Requirements Capture. The requirements activity is automated in a manner that facilitates the involvement of the real stakeholders in the specification of the business, software and IT service, in a language that is entirely natural to them and to engage meaningfully in distributed Agile processes.
3. Automation of Common Service Patterns. The Service Factory frameworks that bootstrap service implementations will increasingly automate many of the common architectural and business model styles. Yet unlike the de facto application package products, the Service Factory will facilitate the extension and customization of the common pattern to allow competitive differentiation for the customer organization, as well as ongoing flexibility.
4. Service Portfolio Management. The Service Factory must support the management of the “business service” and provide tools that integrate demand management, architecture and governance over a composable and constantly evolving business and software service portfolio.
6. Pattern R&D. An important role of the service factory will be to continuously evolve patterns to enable and support innovation in styles of business service together with increased scope of automation coverage
7. Architecture Managed Iteration. Pattern based development delivers code that is always compliant with the architecture, but also with meta data that allows full automation of configuration management. This facilitates continuous, low effort iteration in the delivery, test, DevOps cycle and evolution in production.

In their paper, Chase and Garvin quote Drucker who noted that the imperatives of information-based competition are breaking down barriers within businesses and making functional divisions obsolete. To my mind, the primary characteristic of Service Factory 2.0 will be the realization of the business, software and IT service as a composite offering, architected, designed and delivered as a business asset.

[1]  The Service Factory, Chase, Garvin, HBR

Link: Everware-CBDI Service Factory as a Servicehttp://agileservicefactory.com

9 years, 7 months ago

Service Factory 2.0

by

In July 1989 the Harvard Business Review published a seminal article by Chase and Garvin titled The Service Factory [1]. They argued that “The factory of the future is not a place where computers, robots, and flexible machines do the drudge work. . . the next generation, then, will compete by bundling services with products, anticipating and responding to a truly comprehensive range of customer needs.”

Since the publication some 25 years ago, much has happened to validate Messrs Chase and Garvin’s thesis. The world has manifestly transformed into a “service based world”. By some accounts the service sector grew to over 80% of the US economy by 2000. There are various implementations of the Service Factory concept; we might observe that the ubiquitous Call Centers represent a scalable, repeatable factory model. Similarly in the technology world services, or APIs, are a central part of many IT architectures, and some firms have adopted a service factory model by separating service and solution delivery.

But it must be said that for most enterprises there remains a significant gap between the business and software services. Over 25 years ago Chase and Garvin recognized this as an issue. They use the example of how 200 years ago horse-drawn carriages were mostly made by craftsmen, and the most successful carriage maker was invariably the most accommodating for the customer. But as mass production overtook craftsmanship customers came to value standardized, lower price more than higher price, personalized products. Gradually manufacturing became separated from pre and post-sale customer facing activities. In recent years in some industry sectors, there has been a noticeable reversal of this trend, and mass customization is widely practiced. However in many industries, notwithstanding Agile methods focus on customer involvement, the design of business services remains a discrete activity from the architecture and design of IT services.

This is starting to change. The Mobile revolution and the Internet of Things will inevitably cause a convergence of business and software services. I have described this as “turning the business inside out”. In future it will be a very rare business service that isn’t delivered by a software service, at least as an option or complement. It’s a racing certainty that Call Centers and other conventional service delivery models are going to go the same way as Telephone Exchanges, Typing Pools and Airline Reservations Departments! In this fast emerging world, “everything is a service”. And this will have a profound impact on the shape of the Service Factory of tomorrow.

The Service Factory 2.0 will be a software factory separate from solution delivery projects. As discussed some firms already employ this organizing model in order to architect and design services to standardize core business information and rules for use in many processes.

The software factory concept has been in use for some time, particularly in conjunction with the Product Line concept, where common components are delivered using a framework of tools, repeatable processes and patterns, that are reused in solutions supporting the Product Line. The Service Factory 2.0 is a specialization of the software factory, with a framework that is specific to services. However the most effective service factory will also be a “business service” delivery model in which the life cycle of the business, software and IT service perspectives are integrated.

We can anticipate a number of critical innovations that will enable the Service Factory 2.0:

1. Everything is a Service All business capabilities are delivered as modular software services which are integral to the holistic business service offering.
2. Automated Requirements Capture. The requirements activity is automated in a manner that facilitates the involvement of the real stakeholders in the specification of the business, software and IT service, in a language that is entirely natural to them and to engage meaningfully in distributed Agile processes.
3. Automation of Common Service Patterns. The Service Factory frameworks that bootstrap service implementations will increasingly automate many of the common architectural and business model styles. Yet unlike the de facto application package products, the Service Factory will facilitate the extension and customization of the common pattern to allow competitive differentiation for the customer organization, as well as ongoing flexibility.
4. Service Portfolio Management. The Service Factory must support the management of the “business service” and provide tools that integrate demand management, architecture and governance over a composable and constantly evolving business and software service portfolio.
6. Pattern R&D. An important role of the service factory will be to continuously evolve patterns to enable and support innovation in styles of business service together with increased scope of automation coverage
7. Architecture Managed Iteration. Pattern based development delivers code that is always compliant with the architecture, but also with meta data that allows full automation of configuration management. This facilitates continuous, low effort iteration in the delivery, test, DevOps cycle and evolution in production.

In their paper, Chase and Garvin quote Drucker who noted that the imperatives of information-based competition are breaking down barriers within businesses and making functional divisions obsolete. To my mind, the primary characteristic of Service Factory 2.0 will be the realization of the business, software and IT service as a composite offering, architected, designed and delivered as a business asset.

[1]  The Service Factory, Chase, Garvin, HBR

Link: Everware-CBDI Service Factory as a Service

11 years, 10 days ago

The Next Big Leap: Everything is a Business Service

by

Since the 1970s, authors like Alvin Toffler[1], Daniel Bell[2] and John Naisbitt[3] have predicted the post-industrial society. They forecast the end of the industrial era and the dominance of services and information. This is not a new message[6]; the entire service provider industry has reformed around this idea, and in the USA today non-manufacturing industries account for almost 90 percent of the economy. Virtually every product today has a service component to it and many products have been transformed into services.

One of the most interesting examples of this is the Amazon Kindle service which provides an integrated front end to a wide range of Amazon services. The Kindle service optimizes purchases of books plus access to library and new services and automatically synchronizes all the devices the user may use to access the services including the Kindle reader, smart phone and browser.

Amazon was a pioneer in use of Web services. They are well known for their internal policy of mandating that all Amazon systems functionality should be created as externalized services – that is ready for use directly by customers, and this has clearly been at the heart of their considerable success.

However few large enterprises are able to operate in such an agile manner. Amazon was built from the ground up to be an IT enabled business. In larger enterprises generally there is weaker connection between business and IT, plus the challenges of legacy application and infrastructure base and typically immature (application) service portfolios. And we can all observe the archetypical enterprise is becoming even more complex with pressing demands to respond to major market trends including mobile device based processes, analytics and real time business intelligence driven process behaviour. In this frenetic environment, how can we avoid purely tactical responses which simply generate more complexity and legacy?

CBDI suggested the answer to this problem over ten years ago. The basic service model provides an efficient and effective architecture that enables reusable capabilities that limit complexity and enable continuous change through separation of concerns. However to be truly effective the service model needs to be integrated into the entire business ecosystem where EVERYTHING IS A BUSINESS SERVICE where, like Amazon, all business capabilities are published as integral components of product and service delivery. To achieve this, the service model must be expanded way beyond the prevailing technology centric SOA approach and become an holistic business service centric model subsuming PEOPLE, PROCESS AND TECHNOLOGY.

Of course there will be decoupling between business services and software services; it will be vital that business services are formed from reusable, common software services that can be rapidly assembled into new business processes to allow rapid response to changing business needs.

Of course this all sounds very fine, but most readers will ask the key question “how do we manage the transformation to a service based enterprise?”  There are so many cultural, political, budgetary and legacy challenges that will stop such an endeavour in its tracks. Most business managers have already dismissed SOA as a technical exercise and remain focused on delivery of urgent business programs. Frankly this is THE CHALLENGE. We all read fine statements from F500 CIOs and CEOs who boast about their transformations, but in practice business as usual perpetuates conventional separation of business and IT.  We have to communicate this from the rooftops!

Some ten years ago CBDI defined a maturity model and roadmap approach that showed how SOA capability maturity moves through the stages of Early Learning, Applied, Integration, Enterprise and Ecosystem. Since then this methodology has been used by many large corporations worldwide, including notably Intel Corp[4]. In the Ecosystem maturity stage the service portfolio is integrated with business concepts and federated both internally and externally. However few enterprises have achieved this level of maturity. Amazon is a rare exception.

Many enterprises are embracing Cloud computing recognizing this architecture can introduce a critical level of virtualization and agility. In recent months there has been much interest in moving Cloud to the next level referred to as Everything as a Service (EaaS or XaaS).  HP, just one of the service providers making moves in this space defines this as “Through the cloud, everything will be delivered as a service, from computing power to business processes to personal interactions[5].” This is a very significant advance, however we need to emphasize that Cloud EaaS is a technology centric model, and there’s considerable effort required to integrate with the broader business and IT to avoid yet more legacy.

 

A first step in making this level of transformation is to establish a reference architecture that is entirely service based, spanning business and IT. Frankly existing reference architecture efforts such as TOGAF, OASIS, Zachman etc are not helpful in this area. Rather the service reference architecture needs to provide a mapping to a multiplicity of (stakeholder) views identifying key elements of pattern, standard and policy to ensure appropriate levels of consistency and governance.
Each of the views should also be documented in reference architecture, enterprise architecture, solution architecture and analytics levels of abstraction. You may be wondering why analytics? This represents a further level of cross cutting solution abstraction.
As discussed the reference and enterprise architecture views should be developed to achieve the minimum necessary level of consistency relevant to the business strategy context. 

Everything is a Business Service is the next big leap. Enterprises who have established effective SOA environments will be well positioned to make this move, but recognize it’s going to be yet more steps along a much longer journey than we CBDI articulated in our research 15 years ago.

  [1] Future Shock

  [2] The Coming of Post-Industrial Society

  [3] Megatrends

  [4] Service Oriented Architecture Demystified, Intel Press 2007

  [5] http://www.hp.com/hpinfo/initiatives/eaas/index.html