David Sprott

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

Standardization is a 15 Letter Word

by

My old friend Dan French penned an interesting blog last month. He was thinking about how the common answer today to the question of how to drive efficiency (and thus profit) in big companies is around transformation and standardisation in common processes, a shift to shared services and common, single instance global ERP systems. Dan pushes back against this orthodoxy using the metaphor from a sailing friend, suggesting the very interesting question to ask with all these initiatives is “will it make the boat go faster?” A leading indicator of success in ocean racing is to have a fast, and consequently light boat, and the corollary in business is the question of whether independence and individual business unit responsibility actually delivers more than enterprise level process standardization?

Dan doesn’t actually answer the question, he merely asks how many global leaders in their industries take this particular “road less travelled”?

I discussed the metaphor with one of my customers the other day and he said that in his enterprise, individual business unit responsibility has been a disaster in IT terms. The huge number of legacy applications represent years of local decisions, of reinventing the wheel over and over again. He used another interesting metaphor – suggesting his enterprise was like a tractor pull – where the more successful they were, the greater the weight they had to drag behind them, and slowly and surely that ever-increasing weight is killing them.

And of course this question is relevant to pretty much every large enterprise in the world. As you get big and successful, the agile operating models of early years need to be matured. But frequently these enterprise level transformation initiatives fail, or take excessive time and cost to deliver. The promise of standard COTS products frequently turns into a multi-year nightmare of lowered expectations and massive increase in costs and under-performing business processes.

So enterprises engaged in tractor pull like efforts need transformation, but would probably prefer a fleet of individual racing yachts to a single Titanic. But surely there are other options? Is there not a middle course?

At CBDI we ourselves advocate a service architecture supporting a hierarchy of services with more stable, standardized services in the lower (business state managing) layers and more agile, adaptable services in the higher (capability and process) layers. In this model, variations across business units are managed by patterns that vary behaviors depending upon context and business rules. And there are numerous highly successful examples of this strategy. But is this sufficient? Is this model sufficiently lightweight and agile like a racing yacht?

What I see emerging is an evolution of SOA, in which everything, at all levels, is componentized managed in a framework that coordinates concurrent standardization and differentiation. The figure below shows the key to standardization and differentiation is the configuration catalog that governs the use of components as configuration items.

Probably the most important element of the framework is the Reference Model. Frankly most companies invest insufficient effort in this area. A good reference model is NOT a clone of an OASIS, CBDI or TOGAF meta models, it’s an enterprise specific model that defines how a specific enterprise works. By all means use existing models for the basics, but they must be customized to reflect the specific enterprise. Good reference models are hard work, but they have incalculable value – because you are doing the heavy lifting at the very earliest stage. The reference architecture then clarifies the types of component and their relationship to delivered business processes and solutions.

The central part of the framework is to establish the mechanism by which standardization and differentiation are managed. A Configuration catalog is effectively a logical version of the CMDB. It records the Configuration Items available for a Capability (and it’s a long list including business process, workflow, services, implementation components, portlets, templates, policies and so on). Each Configuration Item is attributed with flexibility options and crucially constraints (policies). The Configuration Catalog is effectively a Software Factory Schema, except that its scope is much broader than software development, covering the entire range of artifacts including COTS products, internal and external services as well as custom applications. The Configuration Catalog is the core driver of architecture integrity, providing active governance over the configuration and reconfiguration of components. If a business unit believes it must diverge from the standard configuration, the question will be, is this purely localized behaviour, or is the localized requirement actually part of a broader demand signal? Can the localized behaviour be accommodated within the enterprise reference model, in which case further configuration is not compromised, or is this a genuine one-off?

Over the years I have advised many companies on setting up asset repositories in pursuit of asset management and reuse. While the asset repository is important in recording capability and dependency, it is typically not used as an integral part of active governance right throughout the life cycle, commencing at the planning stage.

For large companies with extended, federated operations, the Configuration Catalog capability represents a significant capability maturity improvement over “basic SOA”. In fact it’s an implementation of a broader component based model that orchestrates a broader range of assets. It allows active management of standardization and variation across business units and geographies; to encourage freedom of action where it’s appropriate and to exert mandatory standardization where necessary.

Managing standardization is not a trivial task – it is a 15 letter word after all. But mandating de facto industry standard COTS packages for strategic business operations is unlikely to drive competitive advantage. Active governance over localization and standardization will allow a concurrent loose / tight enterprise which facilitates a heterogeneous portfolio incorporating, if you will permit the metaphor, fast ocean racing yachts alongside super tankers to accommodate a range of business requirements. And it will make the overall boat go faster!

Ref: Dan’s Blog

Reach for the Maturity Model NOT the Sky!

by

Last week Facebook announced its plans for IPO and it certainly made me stop and think, would I invest my money in a company that has a socialist manifesto epitomized by “the Hacker Way”. Sure lots of people will make a lot of money, particularly Mr Sugar Mountain, but is a company with 85% of its revenue based on ads worth a multiple of 20? Surely the world has grown up in the last decade and we won’t repeat the dot.com excesses?

The smart money right now is on Facebook being a hugely successful business. But I see a number of things in Facebook that worry me. Although it’s a huge network, it’s a very simple, single model business. There’s lots of plans – they could move into search, or games, or transactions. But it’s all speculation about how to spend the IPO money. They are in fact a very small company – some 3000 employees, and, as I said, it’s a hackers paradise. They have the basics of a platform idea where they host apps, but this is mickey mouse compared to Amazon. Similarly their technology is simplistic compared to Google. And their security engineering is plain immature. And that’s where I think they are in general – incredibly immature. They may boast their youth is a strength, but my experience tells me they don’t have a business platform to grow their complexity to expand their business model in multiple directions. The social media space is nothing if not faddish; sentiment could turn on a dime (sixpence) and the hackers wouldn’t know where to turn. Nearly a billion users doesn’t represent maturity, it represents business opportunity that Facebook has not yet leveraged.

I don’t want to bash Facebook per se. Rather I want to demonstrate the importance of the maturity model. If I am advising a huge company I ask myself what represents maturity in this business model. A bank may have relatively small workforce, but have tremendous complexity in risk, compliance and so on. Their workforce is highly skilled and largely comprised of information workers who manage significant architectural complexity. Equally Amazon has become a hugely complex business but with a very simple portfolio of external, customer facing services. They have used architecture to expose business services for the end consumer and platform partners and have cleverly leveraged and extended their core business model off an architectural base.

So while Facebook looks around for ways to spend its IPO money, I will be looking to see how they leverage off their current maturity level. You can’t buy maturity, you have to build it yourself. You can buy more mature companies, but then you have to have the maturity to integrate them successfully. I note Facebook has acquired 10 companies to date, but they have all been “talent acquisitions”. In fact Zuckerberg is quoted as saying “”We have not once bought a company for the company. We buy companies to get excellent people..” When I hear the CEO saying “we bought Xxxxx for their SOA platform and expertise, I will maybe consider them a buy. Until then I will just watch.

Understanding Agility the Hard Way!

by

Agility is one of those words beloved by software industry marketing people. Over time it has become almost embarrassing and meaningless. Yet if you are in doubt I suggest asking Eastman Kodak, RIM, Palm, Yahoo or Nortel what they think the term means. When you don’t have agility you understand it all too well.

In today’s FT John Gapper says: “Kodak’s experience has a lesson for companies in the grip of rapid technological change. As Kenny Rogers sang, “You’ve got to know when to hold ‘em, know when to fold ’em”. Unfortunately, most public companies are run by people who hate folding ’em, and instead keep returning to the shareholders and bondholders for more chips. . . . Few senior executives, when debating options for a technology company in decline, admit defeat and run it modestly. Instead, they cast around for businesses to buy, or try to hurdle the chasm with what they have got. Sometimes they succeed but often they don’t, wasting a lot of money along the way.”

It brings to mind Fred Brooks essay on software engineering. “No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits. In the mind’s eye one sees dinosaurs, mammoths, and sabretoothed tigers struggling against the grip of the tar. The fiercer the struggle, the more entangling the tar, and no beast is so strong or so skillful but that he ultimately sinks.”

When all is going well investing for agility may seem a luxury. Why make capabilities genuinely independent so they can be switched in or out, or truly generic so they can be used in many different contexts if there’s no obvious or short term ROI? By the time you can accurately compute the ROI it will probably be too late.

Ref: Fred Brooks: the mythical man-month, Addison Wesley, 1975