David Sprott

The Agile Enterprise Value Chain

by

Agile methods have not been widely adopted by enterprises. Agile projects remain, for the most part, independent software development activities, and often by design focused on key areas of enterprise innovation. The latter makes sense, but we should question why Agile concepts should not be rolled out more broadly, because there are considerable opportunities for process improvement across wider range of project classes as well as greater coverage of the end to end life cycle.

If we take this broader, multidimensional view, it should also help enterprises to take a more mature position on agile and agility. Agile methods are primarily guiding management and to an extent project management practices. The business value focus is therefore not surprisingly on “project” quality, cycle time and cost. If we take a broader view we can also focus on enterprise level business improvement, governance and end to end process optimization.

Nobody wants to overload an Agile delivery process unnecessarily. But there are key enterprise perspectives that need to be addressed, and good way to figure out which contribute to the overall delivered agility is to model business value. The business value model allows us to a) develop and refine the solution delivery value chain required for varying enterprise and project contexts and b) charter (structure, manage, govern) architecture and delivery projects with greater probability of achieving optimal outcomes. 

Naturally all enterprises and projects have varying needs for business value. Yes, fastest cycle time and lowest cost are always important, but we can imagine that these will be reasonably compromised for the right business improvement, or reduced risk. A good place to start therefore is by considering the agility related business value required for a project, scenario or enterprise in its broadest sense and relate this to delivery life cycle outcomes. In the simple model below I have listed some practice domains and potential outcomes and then mapped these to candidate business benefits.
Agile Outcomes Mapped to Business Value (Example Fragment)
I have focused Agile practices on Lean process values because these seem to encapsulate all the various Agile methods. In addition I have included disciplines that focus on typical enterprise activities including architecture, asset management, application lifecycle management and automation. I don’t pretend this list is exhaustive, it’s merely illustrative. I am sure readers will have many ideas for practice domains and relevant outcomes. I then mapped this starter list against business benefits using the very effective approach that I cribbed from COBIT5 when I was developing extensions of same. FYI P: Primary, S: Secondary.

This analysis then provides structured data on which to develop an agility value chain (diagram below). I’m sure readers will be very familiar with this technique, first described by Michael Porter[1].  For further explanation see my introduction in Realizing the Agile Enterprise.
Agile Enterprise Value Chain
There are some key points to make about the agile value chain:
1. The primary activities are a cohesive set of activities, and it is important to optimize value across the entire life cycle. For example:
– Addressing software development alone is likely to be suboptimal.
– Making sure that demand is understood, grounded in business strategy, aggregated across lines of business and geographies where appropriate, decomposed into optimal units of work, consolidated into units of release and so on is key.
– Establishing clarity of purpose and matching with an optimal delivery approach.
– Integrating the activities of architecture, definition and delivery in a continuous value chain that minimizes architecture and definition efforts based on value creation. 

2. The value of primary activities can be dramatically enhanced with good supporting activity.

3. That supporting capabilities may be delivered using primary activities which either have qualified goals and objectives, or that the outcomes of primary activities are harvested to create supporting capabilities. For example, in the typical enterprise there are frequently considerable benefits to be gained from reusing many types of asset such as  services, components, schema,  platforms, patterns etc. but it is relatively unusual for enterprises to capitalize on these opportunities for a multitude of reasons including politics, budgets, ownership and support. However if the potential value can be demonstrated and quantified in terms of reduced delivery times and costs, then a business case can be made to put effective systems put in place. 

4. Agile concepts do not just relate to software development! There is great opportunity to adopt key Agile concepts including particularly Lean, Kanban and Scrum, across the entire delivery value chain, particularly for primary activities such as demand and define, and supporting activities such as governance, architecture and delivery infrastructure.

5. That few enterprises are independent, and collaborations are part of business as usual. Further, innovative forms of collaboration may be actively pursued relative to the enterprise’s goals, which might result in widespread use of a common platform, business or technology services, or involvement of unconventional partners such as brokers or social networks.

The Value Chain provides a framework for analyzing the relative business value of the capabilities involved in product delivery in terms of agility outcomes.  In the table below I have shown just a small fragment of what this might look like. I have decomposed each Value Chain Activity into capabilities and assessed potential agility outcomes. Some very obvious extensions would be to include scoring (weighted support to business level benefits) plus inter capability dependencies. A logical conclusion might be to quantify value in terms of cycle time hours or cost reduction, but this seems unnecessary for our purpose here.

Capabilities Mapped to
Agility Outcomes  (Example Fragment)
The detailed Value Chain provides a structured basis for creating and communicating delivery life cycle templates. And it occurs to me this could be just the way to address the elephant in the room for many enterprises – the SDLC standard, commonly a formally mandated standard that is all but ignored by most projects. For most enterprises I believe there are just three basic delivery patterns which provide three template choices, and I will expand on these shortly. I will also be discussing all of the value chain activities in some detail.
Talk to Everware-CBDIabout the Agile Enterprise Workshop. This is currently available as an in-house, intensive workshop. Public scheduled classes will hopefully follow next year.

[1] Porter, M.E. (1985) Competitive Advantage, Free Press, New York, 1985.

Realizing the Agile Enterprise

by

Have you noticed? Organizations have become initiative driven. Ten years ago enterprise architecture was topic de jour precisely because of initiative fatigue. But today there’s a huge focus again on narrow focus strategic projects and programs, because they are (perceived to be) the only way to deliver business change fast.

Architecture, especially enterprise architecture, has become yesterday’s issue – primarily, many would argue because it failed to deliver the promised business agility. Challenging for the same mindshare but at the other end of the spectrum are Agile software development methods that bring an almost religious zeal to rapid delivery by concentrating responsibility on self-managing, cross functional teams. Don’t get me wrong, narrow focus teams are highly effective in solving complex problems that are intrinsically narrow in scope. The problem is that many enterprises are inherently complex, and well executed architecture is the only way in which complex problems can be broken down and structured in order to establish appropriately independent units of work that can be addressed in an effective manner using Agile methods.

There have been several well intentioned attempts to evolve Agile methods to be effective in an enterprise context, to deal with the inevitable complexity that goes with very large scale operations that demand high levels of regulation, governance, scalability, standard services and business processes. But these efforts are unlikely to succeed because they approach the problem through the narrow lens of the Agile methods.

At the same time we should observe that use of UML based model driven methods and tooling has not become widespread, as was once anticipated. Agile methods provide no guidance on “how” to undertake tasks and Agile practitioners by my own observation commonly reject the rigor of formal methods and tools. This single action without question limits the scalability of Agile projects making continuous change and iteration an effort intensive and lower quality activity.

Many enterprises have voted with their feet and in their use of Agile methods have adopted a hybrid approach commonly referred to as Water-Scrum-Fall. In other words, architecture, planning and requirements are undertaken in the time honored fashion, and development is executed using Agile methods, typically Scrum. In truth, Water-Scrum-Fall should be designated an Anti-Pattern because it perpetuates the inefficiencies of early phases and renders the Agile development process sub-optimal because conventional levels of requirements errors and development and test driven rework persist.

What’s happened is that Agile methods have in the main been adopted in a relatively uncritical and immature manner. It’s very noticeable that proponents of Agile methods strongly advocate adherence to the core concepts and methods, citing the transformational nature of the approach and the inherent dangers of compromise. Yet there are examples of Agile being used effectively in large scale, but these are the exception, and have usually been achieved with either, exceptional levels of skilled resources, or more probably considerable customization of method, together with high levels of structure and tooling.

One must conclude that adoption of Agile methods remains at an early stage of maturity, and that like many new ideas in many domains, will be evolved by convergence with depending and dependent practices, which themselves must also evolve.

A practical way to manage this maturing process is with a value chain of the business change delivery cycle.
Whilst architecture and structured methods and tooling are important as discussed, it’s clear there’s a larger ecosystem that Agile methods must collaborate with. This collaboration cannot be approached in a casual manner, it needs to be specified in detailed processes, practices and deliverables with appropriate automation to bring high levels of discipline to the end to end delivery process. It’s time enterprises applied the same level of process change effort to the IT activity that it does to the broader business. In this business improvement process it’s also important to note that Agile concepts can be productively applied to a broader range of activity than purely software development. And as with any value chain, there’s great opportunity to organize the supporting activities and leverage common practices, methods, resources and assets.

The very pace of technology change means today’s enterprise is inevitably going to be initiative driven, but this doesn’t mean initiatives should be isolated in order to be successful – this is a path to delivering instant legacy. Rather Agile methods and concepts are effective Organizing and Management approaches, and they need to be integrated into the broader value chain, particularly architecture and life cycle automation, that delivers rapid business change. 

Talk to Everware-CBDI about the Agile Enterprise Workshop. This is currently available as an in-house, intensive workshop. Public scheduled classes will hopefully follow next year.

Agile Manifesto for the Enterprise

by

The Agile Manifesto is rightly held in high regard, but most practitioners understand it was a response to the prevailing environment in 2001. In fact I note Scott Ambler attempted a rework of the manifesto in 2010. Specifically Scott replaced software with solution; customers with stakeholders. And in context with the Principles behind the Manifesto, he suggested improvement of the overall IT ecosystem be taken into consideration and that Agile can benefit from the Lean Principles.  

But many organizations are finding it hard to scale Agile in the enterprise and much of this difficulty is because of the adherence to specific Agile guidance. In developing the Agile Enterprise Workshop (more on this very soon) I feel it’s imperative to have clarity of how we interpret the Manifesto. So I am using Scott’s work as a basis for addressing key enterprise issues as follows:

Individuals and interactions with lean processes and tools
Working services and solutions with essential documentation

Stakeholder collaboration with agile contracts

Responding to change is intrinsic to the plan

Delivered agile architecturewhich reuses and evolves enterprise frameworksand patterns

I’m afraid this renders redundant the preference for the value of items on the left over items on the right.  In addition the introduction of architecture, whilst it may be highly controversial, is essential at enterprise level, where the level of inter-dependency is so high, and the cost of delivering yet more legacy is unacceptable. Strangely the preference of left over right might actually be reasonably applied to the architecture point.

As Scott rightly said, “We’re agile – things evolve, including manifestos”

All comments appreciated!

Agile Business Conference 2012 Report

by

Last week I attended the Agile Business Conference in London. With four concurrent tracks and well over 200 delegates this must of necessity be a report from a personal perspective.

In the opening keynote Diego Lo Giudice from Forrester encouraged the thinking that we are moving beyond IT centricity and IT ownership into a Business Technology world. This was supported by other speakers. Kevin Herry and James Yoxhall gave an outstanding talk on how IPC Media integrated agile, incremental project delivery with evolving business priorities by using value based backlogs and metrics. However it did leave me wondering whether the IPC Media situation was very specific because the business value could be measured with readily available web site measurement tools. In less well instrumented business situations measuring business value is a hard task, and this was reinforced in the special session on value based contracts.

Diego also used the metaphor of the Crown Jewels, a very British concept I guess, to advocate using Agile selectively for maximum benefit. Being an industry analyst of course he was almost bound to show some industry adoption numbers, and these certainly supported the assumption that most organizations are using Agile very selectively. This intelligence was also corroborated in my own discussions with numerous delegates who agreed that Agile is hard to scale out.

However to rebut this to some extent, there was an outstanding talk from John Flenley of SITA (Société Internationale de Télécommunications Aéronautiques). Together with four colleagues, he explained how the endeavour to replatform and modernize common systems and services used by airlines and airports worldwide had been transformed by a highly structured, very large scale Agile approach. In the process John demolished a number of sacred cows (apologies for the mixed metaphor) and described a functionally baselined modernization process using pre-sprint knowledge discovery and specification processes which fed multiple concurrent, distributed (i.e. not co-located) development sprints! In addition they contracted with no less than three outsourcing providers using fixed price contracts based on Function Points. Key to the program’s success was a tight focus on automation and metrics and measurement across the entire life cycle, and the use of rework measurement as a key to governance and program management. My own notes on the session were heavily annotated with the comment “back to the future!”

Another outstanding talk from Dave West of Tasktop, and perhaps better known as the ex Forrester analyst supposedly responsible for coining the term Water-Scrum-Fall. His theme last week was automating ALM, and here he was (see comments below on WSF) on firmer ground. I have long railed against the Agile community that is so heavily People and Process oriented, and so little interested in architecture and automation. So it was a breath of fresh air to hear someone evangelizing full life cycle automation across tool and participant ecosystems. He advocated the concept of the software supply chain in which ecosystems collaborate using tool integration, buttressed with defensive programming mechanisms and automated testing to establish separation of concerns. Yes! Sounds like a service architecture to me. Dave agreed there is a real need for better standards and meta models in this area, which are currently woefully inadequate, and it’s great to see this topic getting air time at last.

Talking about Water-Scrum-Fall, Manav Mehan from TCS recounted his experiences of using the hybrid method and argued that a) using Agile delivery together with largely unchanged planning and requirements  processes is a given for most enterprises and b) that hybrid is merely a stage in a longer term adoption and maturing process. He also described how they gradually evolved the planning and requirements processes. However he explained he received so much negative feedback about the name Water-Scrum-Fall that he changed the name to I3 (Interaction, Incremental, Interactive). Speaking to Manev later I asked whether in retrospect he wouldn’t have been better off just referring to the approach as agile? I’m afraid in my opinion, Dave W’s contribution in this area is less of a step forward and more like a legacy.

And finally to the topic that was almost absent from the conference – architecture. For me architecture (and technology) is at least as important in delivering agile business as people and process, and because I was manning the Everware-CBDI stand I had great opportunity to engage with delegates on the topic. And I can report wide agreement on this point. I attended one session on architecture and it was an interesting user experience, but to me this is an area that, not just conference organizers, but the agile community at large need to engage with.

There’s much more. I haven’t mentioned governance, which was in evidence, but to be honest didn’t impress me too much. More work to do methinks, particularly demand management and architecture governance.

I will leave the final word to Stephen Grafton who ably chaired the keynote and panel sessions. He said, “We are still struggling to define agile with a big A or not!!” And this summarized the conference. There is really good experience with Agile in smaller, tightly focused, or larger highly standalone situations. But for the typical enterprise looking to deliver more broadly based agile business, there’s a great deal of learning required. 

Agile Enterprise Patterns

by

Enterprises are grappling with Agile methods- but there’s much to learn. The basic Agile methods don’t cut it in the enterprise. There are many big questions including:

·       What type of projects can use Agile?

·       How do we coordinate dependencies between Agile and non Agile projects?

·       How do we operate in predictive approach for some projects and empirical for others?

·       How do we choose? Who makes that decision and when?

·       How do we integrate Agile projects into all the enterprise frameworks such as enterprise architecture, life cycle infrastructure, inter project coordination, systems development life cycle standards, deliverable standards, asset management, outsourcing and offshore arrangements, contracts and agreements, budgets, and so the list goes on.

·       How do the frameworks need to change?

·       To what extent should we stick to the core Agile methods? Should we allow diversity of method across the teams? Will methodology creep happen anyway, and should we worry?

·       Is progressive Agile adoption a normal capability maturity problem, that needs to be managed?

·       Which resources should be assigned to Agile projects? How do we ensure they are properly skilled? Do we need to assign our best people to Agile, in which case, what risks are we running in non-Agile projects? Where do we find real Product Owners?

By observation, most Agile use in the enterprise is in development. A subset of Scrum with TDD and XP. Or Water-Scrum-Fall as defined by Forrester. In the Agile world, it seems this is a derogatory tag but in the enterprise it’s a pragmatic response, that allows planning and requirements to be executed in a low risk manner, and some key benefits of Agile, to be realized in development.

The Agile community is starting to understand this roadblock. Scott Ambler’s recent book on Disciplined Agile Delivery[i]provides some general advice on scaling Agile, as does Dean Leffingwell’s open framework Scaling Software Agility[ii]. However both of these useful resources address the issue from the Agile perspective, that is extending the management framework a bit, rather than figuring out what the holistic organization needs to do to facilitate effective Agile delivery.  

I argue that architecture patterns are “at least as important as Agile methods” in delivering “business agility”. But equally there are many opportunities to adjust current practice right across the life cycle to complement Agile projects.

The Gartner Group have identified what they call Pattern-Based Strategy, and this seems a useful technique – to provide some structure (as opposed to direction) for a proactive approach to Agile adoption which integrates with the momentum enterprise, right across the life cycle, including as I say agile architecture. By using patterns (and more detailed playbooks), we can guide and coordinate practitioners in all disciplines to engage with agile thinking to find sensible answers. I have set out below my starter list of patterns with a bare minimum of classification.

I note that Schwaber and Sutherland in their excellent book Software in 30 Days[iii], recognize that empirical methods are applicable to any form of project, not just development. They give the example of using Scrum for managing the implementation roadmap of Agile. Perhaps more interesting is the applicability of Kanban, which just may be more enterprise friendly than Scrum, to demand management, architecture, release management etc. Of course it’s important that enterprises and their teams understand and adhere to the fundamental principles of the empirical approach.

Strategy-Based Patterns

Agile EA

Product Definition

Agile Family/Product Line

Water-Scrum

Agile Development

Water-Scrum-Fall

Agile Solution Delivery

Agile KD/MDA/MDD Infrastructure

Service Provisioning

Service Delivery

Service Offering Delivery

Agile Software Factory

Agile Integration

Agile Maintenance

Hybrid Project Delivery


Agile Governance

Management Patterns

Scrum

Kanban

Scrumban

Kaizen

Contract Patterns

Agile Statement of Requirements

Scrum Change Request Protocol

Incremental Delivery Schedule

Definition of Done

Acceptance Protocol

Agile Project Termination

Late Binding Agreement

Target-cost contract

Progressive Contract

Fixed price per Iteration

Fixed price per Story Point

T&M

Shared Risk

Pay per use

Service Level Agreement

Service Specification

Automation Unit Specification

Security Specification

[i] Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise,
Scott Ambler
http://www.amazon.co.uk/Disciplined-Agile-Delivery-Practitioners-Enterprise/dp/0132810131

[ii] Scaling Software Agility
http://scalingsoftwareagilityblog.com/

Transformation to Agile IT Delivery

by

The number one IT issue for all enterprises today is delivery – responding to business demand for change in ever faster timescales, at lower cost. But in the typical large enterprise, IT is widely perceived to be incapable of responding in a reasonable timeframe and cost. There are many, many reasons for this. Existing application portfolios are frequently a complete mess typically resulting from continual compromises made in order to deliver rapid business change, which commonly result in duplication, inconsistency and increased dependencies. Enterprise architecture typically fails to deliver realizable guidance to delivery teams. Delivery projects are commonly driven by narrow focus, exclusively business centric goals. I could go on.

Because business as usual (BAU) doesn’t deliver, we can observe the “initiative count” increasing exponentially. Initiatives are top management driven demands for results that are frequently outside of the momentum plan. For example, narrow focused Agile projects; mobile IT and BYOD; SaaS projects; package acquisitions; M&A, BPO, outsourcing and offshoring projects etc.  Or technology focused adventures such as application level modernization. And what usually happens is the initiatives become the new silos, which in turn contribute to the ongoing maintenance and integration nightmare.

Over the past decade most large enterprises have established architecture as a key discipline precisely because of the situation described above. EA in particular was always intended to provide a “city planning” perspective, coordinating across domains to ensure consistent business processes and information and to govern standard infrastructure and shared services where appropriate. In many organizations EA has actually been disestablished because it was perceived as not adding business value. In other organizations EA has minimal influence on delivery programs because of the lack of interest in “doing things right” and the over-riding imperative to deliver as quickly as possible, regardless of downstream consequences.

Recognize the picture? The problem is that for most organizations there is no BAU. So the result is that stand alone initiatives become the only way to get rapid results, but the inevitable outcome is that the ability to change the core business is in steep decline. Short term “project agility” is confused with “ongoing business agility”.

The way forward is to view the IT Delivery as a Value Chain. You can’t focus on just one part of the chain such as Agile projects, you need to see the bigger picture and “manage” the way you respond such that business AND IT goals are achieved.

If you recognize this situation, you may be interested in my short Webinar – Transformation to Agile IT Delivery. (Note I recommend viewing in You Tube with high quality 720p)

Categories Uncategorized

Using Cobit 5 Part 3 – The Policy Hierarchy

by

Many companies do not do governance well. A primary reason for this is a focus on governance “process” at the expense of policies. And, where policies are established, it is common to observe a surfeit of bad, inconsistent policies that are overlapping and generally ignored. As a result much governance is carried out by opinion; and governance decisions are not easily repeatable.

The Cobit 5 framework provides reference models for process and goals but, other than providing very general guidance, stops short of any detail at all relating to principles and policy. However in fairness Cobit 5 does recommend “a (hierarchical) structure into which all policies should fit and clearly make the link to the underlying principles”.

So what does a policy hierarchy look like? Does each organization need to invent its own unique structure and content?  Actually we need more than just a policy hierarchy, we need a model that helps us establish a consistent approach to policy search and description. And whilst every organization will have unique needs, much of the hierarchy and policy content will be reusable. What will usually be highly customized are the contexts and their relationships with policy assertions.
 
In the diagram:
– policy type – classifies the policy. It can be hierarchic.
– policy subject – identifies the focus of the policy the class of object being governed.
– policy – a strategy or directive defined independently from how it is carried out
– policy assertion  – is an atomic policy requirement, expressed as a statement that must be true or false
– policy context  – an entity that limits the reach of a Policy.
– policy effect – an intended and/or an actual outcome of a Business Policy. This can be the Principle(s), Goal(s) or Outcome(s), which of course map neatly to Cobit 5.
Let’s look at an example:

Meta Class  Example
Policy Type Architecture        
Policy Subject Application Architecture
Policy Interfacing
Policy Assertion All new Application Interfaces must be loose coupled.
Policy Context Global applicability
Policy Effect Principle: Interoperable; IT Goal: Agility

Now to put this more broadly into the Cobit 5 context, here’s a fragment of a policy hierarchy, mapped to Policy Subect and Cobit 5 IT Goals.

The policy hierarchy shown above is not rocket science. However it facilitates consistency and communication to all the various stakeholders. You could at a stretch manage policies in a spreadsheet, but in practice it would be advisable to use something like Sharepoint or an equivalent, that allows you to manage the life cycle, status and so on. In a further elaborations of this little series of blog posts I will explore policy relationships with guidance and standards, policy assertion and context development plus the broader policy management model.

Reference: 
Using Cobit 5 – Part 1: Principles
Using Cobit 5 – Part 2: Policy Nomenclature

Next Step: Talk to David about how to apply effective, policy based governance.  

Using Cobit 5 – Part 2: Policy Nomenclature

by

As discussed in Part 1, for me the primary value in Cobit 5 is the formalization of policy as a concept that has a life cycle and management process. In CBDI-SAE we have focused very strongly on defining the policy hierarchy and instances as the mechanism by which consistency is delivered and governed. Consequently over the years I have been critical of Cobit 4.1 because it was essentially promoting process based governance – if you are executing this process, with some nodding in the direction of general outcomes, then everything’s OK.

So I am very pleased to see policy introduced in a more coherent manner in Cobit 5. The 4.1 definition of policy was: “Generally, a document that records a high-level principle or course of action that has been decided upon. A policy’s intended purpose is to influence and guide both present and future decision making to be in line with the philosophy, objectives and strategic plans established by the enterprise’s management teams.”

In Cobit 5 the definition changes to: “Overall intention and direction as formally expressed by management.” This is better, but still not quite there. Contrast it with the CBDI-SAE definition: “A strategy or directive defined independently from how it is carried out.” I could ask what does management mean? If it was really necessary to include, then a reference to Governance Board, Design Authority or equivalent might have been helpful.

However, minor irritations aside, what Cobit 5 does is lay down a clear requirement for policy “to be part of an overall governance and management framework providing a (hierarchical) structure into which all policies should fit and clearly make the link to the underlying principles”. Further Cobit 5 separates Policy from Principle – a very important step. Also very sensibly Cobit 5 does not attempt to define policy instances, nor indeed the hierarchy and this allows specialists (such as ourselves) to map and or align our pre-existing hierarchy to the Cobit framework. I will return to and expand upon the hierarchy in the next part of this series. But first I want to consider policy nomenclature and structure in a little more depth.

Cobit 5 says “Policies provide more detailed guidance on how to put principles into practice . . .” This is potentially misleading. Yes policies are practical strategies and directives that support and realize principles, but to suggest they must be detailed is incorrect. Good policies should be formed as assertions that are true or false and should not be detailed with “how” they are achieved. The best policies are those that are mandatory – providing unequivocal direction to architects and service delivery teams. The detail is best left to Guidelines – or recommendations that indicate use of patterns and practices.

This simple error in Cobit 5 is actually a fundamental flaw that I would like to see fixed. Time and time again I come across confusion over the nomenclature being used by our clients to support governance. Confusion in this area leads to poor  implementation and inconsistent governance. The terms policy, standard and guideline are very commonly used, but frequently mean very different things.

In this context, the good news is Cobit 5 has at least defined policy as the overall intention and direction. I will certainly be using this to advise my clients to standardize on this terminology. Guidelines should then be regarded as practice recommendations. These are not policies with a lower level of mandatory status. At some stage they may evolve to become policies, but not necessarily.

Standards are perhaps a little easier. The CBDI-SAE definition is “A collection of rules or practices which are relevant in Service Architecture or Engineering.” And for good measure the meta type Protocol is a subtype of Standard. Standards therefore are clearly defining the mandatory requirement to comply with specific protocols and practices in given contexts.

To summarize, Cobit 5 is a major step forward. It encourages a policy framework and nomenclature standardization on “policy” for the major directives and strategy assertions and doesn’t preclude complementary Guidelines and Standards under a common management process. In addition Cobit 5 provides the outline framework for development of a policy hierarchy and policy instances, which I will cover in some detail in the next part of this series of blogs.

References: Using Cobit 5 – Part 1 – Principles
                   Using Cobit 5 – Part 3 – The Policy Hierarchy

The Integrity Unit Pattern

by

Down the years I have advised customers on the use of an Integrity Unit pattern on numerous occasions, yet strangely this incredibly useful pattern seems to remain a best kept secret.It’s pretty simply really. I define it as: A defined group of ca…

Categories Uncategorized

Time to Rain on the “Cloud Service Model” Parade

by
The Cloud community have been talking recently about Everything is a Service; they call it EaaS. At first hearing it’s an interesting idea, another acronym to complement IaaS, PaaS and SaaS. Unfortunately it’s rather like the tail wagging the dog!  The Cloud community use the term Service liberally but with minimal consistency.


It must be said that the NIST reference architecture document has been incredibly helpful in sorting out the three Cloud service models of IaaS, PaaS and SaaS. However in order to read the document you have to suspend all your knowledge and belief of services and read the document interpreting all references to service as “provision or access to some capability”. In other words as a generic IS service of some sort.


Actually most Cloud infrastructure resources are provisioned as well formed services governed by interface and SLA contracts. There are a few SaaS providers that have implemented an SOA – in compliance with generally accepted principles of loose coupling, separation etc. However most Cloud services are multi-tenant application resources with integration capabilities delivered as Web services. Yet perceived wisdom generally says that SOA is essential for Cloud!


I noted an interesting paper from Intel recently[i]; the thing that really struck me was the way the paper describes how Cloud development as the Wild West (my words), and the author is advocating ideas that amount to rediscovering the SOA wheel!

SaaS and PaaS providers are circumventing traditional enterprise architecture. Compliance and visibility has decreased. Simply put, your enterprise is likely already part of the app economy. The question is, how are you managing your API traffic? Do you have a control point to manage that participation? Enterprise APIs are not science projects; they’re conducting enterprise-class business and require enterprise class visibility and control. What path can enterprises take to prepare for secure use of APIs? Dan Woods, Chief Analyst, CITO Research and Colleagues, May 2012

And the author goes on to describe how Cloud needs to move beyond point to point integration to introduce something that sounds very much like an ESB! So the notion that de facto Cloud practices should form the basis for EaaS sounds fanciful.


Yet despite this, I believe we should look closely at the idea of Everything as a Service. It’s the vision that CBDI and other pioneers painted years ago. What’s really required is a convergence of business and IT service concepts that would provide consistent views for all the various stakeholders in both IT and business domains including the service owner, business service designer, IT service architect, IT service designer, service security architect, provider, IT service manager, service broker, service consumer and so on and so forth. Today we have disparate service models in both business and IT that positively encourage silo disciplines.


To produce some form of unified service model wouldn’t be just an academic exercise.  First it might just facilitate better understanding of service architecture across business and IT stakeholders. Second it might assist in better service design, delivered services that are fully integrated with people, product, process and technology and engineered to deliver individualized services to customers that are architected to be responsive to business change!


But the place to start is to understand the needs and opportunities in a unified service model. This will leverage the Cloud, and hopefully cause more service owners to demand their services are first class software services in order to deliver better customer service. Maybe this will encourage NIST to revisit its reference architecture and give the service perspective a little more integrity.


In this month’s CBDI Journal we publish an article exploring how such a unified model might look, and the business value that it might deliver. We welcome feedback and comments.


Abstract: The Cloud movement is discussing the term Everything as a Service (EaaS or XaaS).  In principle this is a welcome development, encouraging business and IT participants to adopt services and service oriented concepts everywhere. However it appears that the E/XaaS initiative may be more about marketing than reality. In this article we suggest how this very promising idea might be developed to clarify Cloud Service taxonomy and deliver convergence of business and IT perspectives in a Unified Service Model.