What exactly does the term ‘enterprise quality’ mean in this context? Moving past the obvious answer of reliability to manageability then clearly this is an attribute that is required, but in our new world of personalisation and frequent change then what are we trying to manage? Well, obviously quite a few things, but lets assume we are making wider use of ‘cloud computing’ for these new environments. The whole point would be that we should have a workable separation of the normal operational factors we manage in terms of infrastructure and resource allocation in the cloud from the enterprise and user software above.
So what requires managing? In a word Policy, or more accurately Policies, as there are going to be quite a few of them. I started thinking about this a month or two back with an announcement from Jackbe, one of the leading MashUp providers, of Enterprise Mashlets, which is their term for creating Widgets within the Jackbe MashUp environment. The Widgets are therefore created, and managed, within the policies of their MashUp engine. The result is the ability to take advantage of Widgets as small simple ‘active’ integrations MashUp style of data, which can be placed into any other web page still with the same policy control as a full MashUp. (Note; to self must Blog on the increasing usefulness of Widgets).

Back to Policies, where ITIL at least makes a useful start with its inclusion of Policy Statements, but it’s nowhere near going to cover the impact of a ‘build to change’ environment. And that environment is going to embrace everything from the Services in our own SOA, through to external services, as well as enterprise, and user designed MashUps and Widgets. It’s a huge environment where the defining feature is that it is dynamic, and ever changing, and more importantly loose coupled, so by definition any single service, or MashUp element, can be used multiply, and concurrently. Try thinking this one through with current management techniques.
Policy management for this environment is very much still in its infancy, but right now is the time to get some principles in place. Two colleagues of mine, Carl Bate and Nigel Green, in their work on defining ‘a service’, meaning literally an individual service corresponding to a business task, around five principles showed an interesting starting point. Carl has blogged on their work and it’s well worth a read in its own right. The key is first to define the granularity of the service in respect of the business task which they call its ‘Value’ statement, and this also provides the registry name for the service itself.
The remaining four characteristics are; ‘Policy’ – meaning what policies need to be applied to this service; ‘Events’ – which events are involved; ‘Content’ – created or consumed and ‘Trust’ – who can do what. Following the VPEC-T, as they call it, approach means that from the very beginning starting to build up the correct sort of Policies using the creation of the new environment as the focus to determine what sort of policies are needed.
It actually gets better than that because the ‘events’, ‘content’ and ‘trust’ relationships should also be mapped thus creating from the very beginning a reasonable governance structure for maintaining services. If you change a policy clearly you will know which services will be affected, and from that which processes the service appears in, and therefore the impact. The same holds true for Content, Events, or even Trust, it’s a pretty self evident way of getting a grip on what will turn into a huge problem very quickly as the number of services rapidly multiplies.
MashUps, and Widgets pose similar challenges, and here is where I see the benefit of adopting an Enterprise MashUp approach with elements designed from the start to offer both a framework for deployable MashUps that manages the policies with a MashUp engine to perform a similar role with Data provenance. It’s tempting to just use some open source elements and build ad-hoc MashUps that will work just fine, until the issues of managing become apparent. The lessons of the PC era of deploy cheap, and spend a lot of money to re-establish control of ‘information’ under a new role termed CIO, are still a little close in my mind to want to get caught this way again.