Cloud, Enterprise Architecture and The Missing Link


enterprise architecture missing linkOne of the most compelling drivers for Cloud and ITaaS transformation is the time-to-market improvements that come from enabling self-serve access for business users.  Rather than waiting for IT to provision resources, the business can select, configure and deploy services on their own through a service catalog.  With this advantage, the business can more easily respond to changes in customer demand, competitive moves and market trends.

To effectively enable these self-serve models, business users and stakeholders need to understand the services, value proposition, and why they should buy them internally instead of from an external party cloud service provider. For this to happen services need to be fully aligned around business requirements, whether for applications, infrastructure, data, integration or others. Perhaps most importantly, these services need to be defined and described in business, not IT terms.

The assumption for many is that ITaaS service definitions should be driven by enterprise architecture (EA), which has traditionally been responsible for documenting the process, application, data and technology structure of the organization. As EA has documented and defined services and supporting architectures in the past, why would it be any different now?

What many organizations are discovering on the path to ITaaS is that a missing link still exists between service definitions and business users. While the EA function may do an admirable job for example of defining new Data-as-a-Service or private cloud IaaS services, these definitions to little to help bewildered business users determine where, how, when any why they should be used.

This missing link needs to be filled by a new product management function that is independent, but complementary to EA. While some may believe the function should be performed by enterprise architects, we believe it is distinctly different role from EA and SOA disciplines in four key respects:

  1. A product management approach takes a dynamic view of services that acknowledges that services and capabilities will need to change, often rapidly, in the face of market conditions. As product management focuses on business requirements that by nature are constantly evolving, the services portfolio will be designed to change and evolve as well. EA on the other hand tends to take a more static view of strategy, processes, capabilities and services that focuses on “blueprinting” and defining an ideal end-state that may or may not ever be achieved.  This static approach is becoming less relevant given the pace of innovation and change facing many business stakeholders.
  2. Product management defines services from a “top-down”, business requirements driven starting point, not from a “bottom-up” technology perspective.  While EA certainly encompasses mapping of business process to capabilities and technology, the function typically sits in the IT organization with IT “clients”.  This top-approach is by definition better aligned with business requirements and needs.
  3. The overall focus of product management in an ITaaS model is on optimizing service portfolios and definitions to maximize business self-service to capture agility benefits. The focus on EA typically has more to do with ensuring a logical overall services architecture, and that the house has been designed according to standards and best practices with everything “up to code”. Product managers ensure that the house is comfortable, livable and usable for the inhabitants.
  4. Product managers will provide roadmaps that are developed with an appreciation that services can be provided via SaaS, PaaS or IaaS services, or by internal or external service providers. Product managers acknowledges that these choices are dynamic and evolving, whereas EA tends to take a more static view of service delivery.

So given the fundamental differences, what do these new product managers need to do from a tactical perspective?  What’s required to effectively define business services, and what does a product manager need to do?  In our mind, in successful next generation IT organizations the product manager will:

  • Define business services portfolio required to support a specific business function (i.e. Marketing) or set of common stakeholders.
  • Develop and owns the service / capability roadmap required to support current and anticipated business requirements.
  • Refine the portfolio and services roadmap as necessary in light of changing competitive dynamics, trends or technology evolution.
  • Serve as a trusted advisor to business stakeholders on emerging services, capabilities and technologies.
  • Develop and optimize service sourcing strategies, whether it be provided internally or by 3rd party cloud service provider.

This new service product management function will be a critical success factor for effective cloud and ITaaS transformation programs as it will:

  • Provide business and IT stakeholders a mechanism for managing an ever-increasing pace of innovation and change.
  • Optimize service delivery from a business outcome, rather than technology perspective.
  • Tighten the linkage between business service requirement and technology capability, enabling greater agility and time-to-market acceleration.

To effectively compete as a service provider, the enterprise IT organization needs to evolve. Recognizing the need for a new product management capability that is distinct from the EA function is an important start.

 

Comments

  1. Have you implemented this structure completely with any of your clients? What was the lessons learnt from the implementation? Are you implying that product managers (its a terrible title by the way as it conjures up images of product managers trying to sell “products”) sit in the business organisation? Are they then expected to understand services and how flexible and readily adaptable those services are?

    • Michael – yes, we have several clients that are currently moving in this direction. The product management role will still sit in IT, but focus on developing and maintaining services roadmaps based on business requirements. While I agree the name is not ideal, the role and function is really what’s important. In my mind at least the product manager doesn’t “sell”, but rather constructs a portfolio of internal and external services based on user demand and requirements. If the PM does their job right the services should sell themselves!

    • I appreciate this point of view. Yet, the product manager moniker brings new light, or another perspective, to the traditional service manager or business liaison role in many IT organizations. I like the analogy as it causes us to look at the services we offer to our business units in a more competitive manner – as a life cycle and as if it was competing with those on the open market. You could take this notion a bit further and build a maturity model that reflects the evolution of such roles. Perhaps the additional activities of a traditional product manager add more maturity to the traditional business liaison or service manager role?

      • EA is more than a technology function. Or it should be.
        Besides, the EA should not be responsible in the first place for specifying the capability to be outsourced to the cloud. That would be indeed the business stakeholder task.
        EA should make sure that all alternatives are analysed, the solution integrates in the rest of the landscape and does not incur additional or duplicate functions.

        But I don’t think there is a need for such a function that would have to manage all new cloud developments apparently.
        Anyway, rather than product management you should call it capability management.

Speak Your Mind

*