Cloud Service Design and Evaluation
Any cloud initiative, hopefully based on a cloud strategy, policy and roadmap, will have to start with the definition of the requirements as part of service design and aligned with the overall sourcing process. Part of service design is the evaluation of cloud service available on the market (external or internal service portfolio) based on the previously stated requirements. Usually, such evaluations are part of the due diligence stage of the sourcing process. Methods of evaluations are proof of concepts, trial periods and reference installations. The original requirements are instantiated as service acceptance criteria in contracting, finally to be tested in service transition.
Of the various methods and concepts defining and managing requirements (from definition to acceptance), there is an arising move toward agile methods. One advantage of agile methods is the concept of “stakeholder written user stories”. Meaning: cloud service stakeholders would define the user stories covering all aspects of the expectations to the to be introduced cloud service. Cloud stakeholders would be any role in a customer organization, either using and supporting or being concerned with, and/or affected by the new cloud service.
Therefore, I want to reflect on the marriage of two different worlds: The agile user stories world coming with concepts like scrum, devops or Kanban with the newly defined standard cloud roles world as stated in the in the ISO 17789 norm ” Information technology — Cloud computing — Reference architecture”.
Agile User stories
There are many qualities, agile user stories can add to proper defined cloud service requirements:
- “stakeholder written” means defined by all relevant roles having a vast interest in the service expressed in their language.
- user stories are simple and concise
- stating acceptance criteria and the expected benefit of a service functionality or a service warranty.
A typical template for a user story would look like:
In my role of a [any service stakeholder role], I want to [service functionality, outcome,warranty] so that I am able to [service value, benefit].
The definition of “Done” attached to any user story will form the criteria for acceptance during testing, review, trial or proof of concept and transition.
User stories should be simple, concise, implementable and testable within sprints. On the other hand, managing a big junk of stories can be challenging. To overcome the issue, user stories can be grouped under overarching “epics” and/or structured according to different “themes”. Cloud related epics for instance can be the collection of all cloud integration user stories under an epic “Integration”. All security relevant stories can be grouped under a respective “Security” epic. Cloud themes are common, cross-functional topics like “user access” for all possible cloud services models (IaaS, PaaS, SaaS).
Cloud Roles relevant for defining user stories
To match cloud roles to cloud relevant user stories, I am referring to the defined standard roles:
Cloud service user, those, who are actually using the cloud. That could be a business “end-user” using SaaS services, an application developer making use of PaaS services developing new cloud based applications or a IT product manager (or Cloud Service developer, see below) designing, transitioning and operating platforms or application on top of an IaaS service.
Cloud service administrator, the role on customer side who is overseeing all the operational processes relating to the use of cloud services and acts as the focal point for technical communications between the cloud service customer and the cloud service provider. One could say this is the service (operation/delivery) manager role known from the traditional IT.
Cloud service business manager, the one who owns all the financial and portfolio/lifecycle aspects of the service on behalf of IT in front of the all the cloud users. Easy to mentioned that this is the known service owner role in traditional IT.
Cloud service integrator, which is responsible for the integration of cloud services with a cloud service customer’s existing ICT systems, including application function and data.
Cloud service developer, which is responsible for designing, developing, testing and maintaining the implementation of a cloud service. This can involve composing the service implementation from existing service implementations. This role has nothing to do with software development using PaaS, it is more the traditional IT product manager, solution architect, engineering role in traditional IT.
Cloud auditor, with the responsibility of conducting an audit of the provision and use of cloud services. A cloud audit typically covers operations, performance and security, and examines whether a specified set of audit criteria are met. Roles known from traditional IT covering this area are security, data, quality and internal audit management areas of responsibility.
Cloud service broker, negotiating relationships between cloud service customers and cloud service providers by matching the demand (tactical and strategic business/customer requirements) with the global marketplace (service portfolio) of available cloud services. Actually, this role could be considered as the leading role for all service design activities aligned with the sourcing process (provider selection, including rfi, rfp, due diligence, contracting).
The real roles in a real organization don’t have to be and certainly will not be an exact match with a standards, especially if an organization is at the beginning of a cloud journey.
Cloud User Story Examples
Here are some examples of typical user stories supporting cloud service design aligned with the standard cloud customers and partner roles:
ISO Standard Role Cloud service user:
In my role of an application manager, I want to be able to order a middleware instance which should allow me to deploy a simple JEE based web application so that I am able to deploy application code to newly provisioned/existing PaaS infrastructure fast and easy.
Acceptance criteria: Within 1 minute, Web application is provisioned with all its required resources and is available via http.
Epic: PaaS
Theme: Instantiation of service
ISO Standard Role Cloud service administrator:
In my role of a service manager, I want to have access to a real-time service performance dashboard, that I am able to regularly check the status of agreed SLAs and to avoid or manage escalations.
Acceptance criteria: Performance figures can be viewed/retrieved on/from the self-service portal, Monitoring figures can be viewed/alerted on the self-service portal.
Epic: Shared Service attributes
Theme: Reporting
ISO Standard Role Cloud service business manager:
In my role of a service owner, I want to have an agreed service recovery time objective and a defined service recovery point objective so that I am able to guarantee IT service continuity as required by my business.
Acceptance criteria: agreed RTO: 1hour RPO: 4 hours reviewed conceptually and ready for contracting
Epic: Shared Service attributes
Theme: Governance
ISO Standard Role Cloud service integrator
In my role of an Identity and Access Manager, I want to ensure Authentication / Authorization of internal communication (TLS, use Customers PKI Certs for TLS), Active Directory Integration and SNIAM/CD Integration concerning Functional Roles and User assignments so that I am able to ensure adherence to our internal architecture, security and compliance policies.
Acceptance criteria: all connections protected by TLS (for PoC, self-signed certs are ok but use of PKI has to be possible), Detailed architecture/white paper drawn up for required AD integration, showing components and interfaces, Detailed architecture/white paper drawn up for required CD integration, showing components and interfaces
Epic: Service Integration
Theme: Network
Advantages of this approach
Firstly, the role based stakeholder involvement concept ensures, all relevant requirements coming from different areas (business/customer, security, integration, service management) are being covered. Secondly, good written user stories are an excellent pre-requisite for any agile cloud service evaluation and transition approach. Most of the more mature cloud service providers used to live in the agile world, they are very familiar with the user story concept and would appreciate to base the collaboration with their customers in service evaluation and transition on those concepts.