IT Governance: how much are we walking the walk?
The "G" word is one of those words that's bandied about with increasing abandon these days - but for many, "governance" is just a more sexy way of saying "management" (in the same way that "architecture" is quite often used as a sexy way of saying "design").
So how much are organisations really walking the walk with IT governance initiatives? This is something we're expending significant effort on finding out through 2009, and one of the ways we're doing it is through surveys like
this one, which we're carrying out in conjunction with CIO UK magazine.
We'd love to know
your thoughts. We'll make sure we point to the results back here (they'll be published at cio.co.uk) and we're sure they'll throw up a load of interesting insights.
Labels: CIO, governance
Collaboration momentum building in 2009; what do CIOs think about IT Governance?
A few days ago the results of our second CIO UK poll were published in this piece -
CIO Debate: Collaboration is building momentum in 2009. The poll corroborated earlier research that we carried out for our
Collaboration advisory service in the summer of last year, in conjunction with the guys at Freeform Dynamics.
The headline findings: despite all the hype, collaboration adoption is still just getting underway. A big part of the reason for this is the difficulty of justifying big up-front infrastructure investments. Where collaboration is growing fastest, though, it's business activities "at the edge" - those involved in interactions with external parties - which seem to be driving things along. There is a significant amount of appetite for collaboration technology, though, and our research indicates that 2009 will be quite a strong year for collaboration technology adoption.
Our third CIO UK poll is now live at
cio.mwdadvisors.com, and this time we're asking a handful of questions about approaches to IT Governance. How many organisations are pursuing formal IT Governance programmes, and if so what are the reasons? Are they basing their efforts on established frameworks like COBIT and ISO 38500? And what are their plans going forward? Those are some of the questions we're looking to explore.
If you're a CIO or IT Director - or you know someone who is - please take 2 minutes to provide your input (or send your contacts the
link)! We'll be publishing our CIO UK Debate piece on this topic in the next few weeks.
Labels: CIO, collaboration, governance, MWD, poll
On SOA governance: for SOA, read CPOA?
A couple of weeks ago I was the happy recipient of a review copy of the excellent Todd Biske's
SOA Governance book. Todd's "
Outside the Box" blog is one of those rarities where every post is worth reading twice - so I was very interested to see whether his writing ability might stretch to something the length of a book! Todd's clearly established himself as someone who has a lot of insight on the topic of SOA Governance, so I was pretty sure I wouldn't be disappointed.
A number of other bloggers have posted detailed reviews of Todd's book, so I'm not going to do exactly the same here. Take a look at the
Amazon comments if you'd like to see what they said.
For me, I'll be brief: SOA Governance is a very good book indeed, in that it does something that so many technology and business management books fail to do: it breaks a complex and hype-laden subject down into very manageable chunks, and walks through the topic clearly and at a steady pace - but it still manages to move quickly enough to prevent the reader getting bored. It's not a perfect(*) book, but then nothing is - and if it had been, I would have been too jealous to write this. We need more technology/business management books like this, and we needed just such a book on SOA Governance. Well done Todd!
I knew this was a good book because it made me revisit some conclusions I'd already had washing around in my own head for a couple of years.
One of the things that I still find as I travel around is that when I get into discussions about SOA, there's way too much focus on the "S" and not enough focus on the "A". It's almost as if we've been blinded by technologies and standards which have "service" somewhere in their names, and aren't able to look at the bigger picture.
What Todd's book reminded me is that if you want to get real value out of service orientation, then it's the "A"rchitecture that really makes things happen. Todd's narrative keeps coming back to his definition of Governance, which revolves around People, Policies and Processes. And it also talks a lot about the concept of "contracts" in the context of analysing how service providers and consumers should work together in order to interact. Without People, Policies and Processes in place to guide your organisation down the right path, and without the concept of "Contract" to focus on the responsibilities that need to be described and assigned when service consumers and providers interact, such an architecture effort will likely lead nowhere. You'll end up with "just a bunch of services".
So - and this was the thought that occurred to me after reading Todd's book - perhaps we shouldn't really be thinking about "service" oriented "architecture" at all. It seems to me that what architects might find more productive to focus on is policies and contracts, not "services". Maybe "service" is better thought of as a concept that describes the outcome of this kind of architecture approach. And so maybe it's the case that there are two things in play here, and we're getting them mixed up: contract- and policy-oriented architecture (CPOA ;-) and service-oriented IT delivery?
What do you think?
(*) one thing I found rather strange was that despite a word at the front to reassure readers that they didn't need to know any technology detail in order to read the book, at a number of points you're suddenly confronted, out of nowhere, by XML fragments which (as far as I could tell) didn't really add any value. That's a tiny niggle though.
Labels: contracts, governance, policy, SOA, toddbiske
SOA governance and data governance - separate or one in the same?
Joe McKendrick (once again!) has
another post which caught my blogreader today. This time he is pondering the relationship between SOA and data governance:
If data governance is inadequate — information is outdated, out of sync, duplicated, or plain inaccurate — SOA-enabled services and applications will be delivering garbarge. That’s a formula for SOA disaster.He goes on to
reference an article by Ed Tittel, which draws the same conclusion:
Amidst all the hype and buzzwords that surround SOA nowadays, it's still far too common for organizations that seek to integrate service-oriented architecture into their IT infrastructure to omit issues related to data integration, management and governance in their designs. As they roll out and learn to live with an SOA, however, they often discover that interoperability with other systems and solutions poses interesting problems. In fact, these problems can make interaction between systems and SOA components both vexing and time consuming.
Absolutely! When we put together our
SOA Strategy Planning Tool, we explicitly acknowledged the importance of a common information model that provides:
standard representations of core information types for communication between servicesWhere I deviate from Joe and Ed, however, is their perspective that data governance and SOA governance are separate disciplines. Without inter-service communication there's no SOA and so SOA governnance must encompass data governance. Furthermore, that governance needs to extend beyond service design throughout the service lifecyle.
In a subsequent post, Joe calls out
this post from David Linthicum in which he noodles on the same topic. I am not so sure about David's view that SOA initiatives:
need to start with the data first It all depends on the scenario where a service-oriented approach is being applied. However, I agree with him that there is a need to understand:
the core purpose of the data, how it relates to other data, how the data is bound into entities, as well as security issues, integrity issues, and the binding to existing functions or transactions. I would go further and say that it's not just about understanding those things. In the case of security and integrity issues, there is a need to ensure that what is understood is enforced. That means defining service contracts that take account of those requirements and enforcing them through policies. Which brings me neatly back to the SOA versus data governance discussion. Policies are the
lingua franca of SOA governance and policies apply as much to the data flowing in a service network as they do to the services themselves.
If you are embarking on an SOA initiative you need to ensure that those responsible for SOA governance, ideally though an SOA centre of excellence, include individuals with data management expertise. Your governance processes should enforce utlilisation of a common information model and encompass a policy-based approach to ensure that data management objectives and constraints are enforced.
Labels: governance, SOA
Software AG goes in an interesting direction for SOA governance
As part of yesterday's
release of the latest iteration of its webMethods Insight product Software AG announced an OEM partnership with Progress Software. This announcement adds the Actional runtime SOA management and monitoring technology (which Progress
acquired back in January 2006) to Software AG's existing Centrasite design-time governance capabilities (which were bolstered by
the acquisition of Infravio in September 2006) and the runtime policy enforcement provided by its webMethods X-Broker and partner Layer 7's XML Firewall.
The incorporation of runtime SOA management and monitoring functionality into Insight is a necessary evolution of Software AG-webMethods integration strategy that we commented on
just over a year ago. It's long been our position that SOA is more than a standards-based approach to software development and integration. The business value of a service-oriented initiative depends on a recognition that software services are experienced, just like their real-world analogues. The quality of that experience depends on a governance approach that extends throughout the service lifecycle, where the contracts defined when services are designed are subsequently enforced through policies once they are deployed and running - and where runtime metrics are captured to provide insight into the service level quality that is actually exeprienced. Furthermore, those metrics can be used to inform and support change management processes, so closing the SOA lifecycle loop.
Whilst the announcement doesn't come as any great surprise, the source of the runtime management and monitoring functionality does. When Oracle
confirmed it's intention to acquire BEA, I said:
It [the acquisition] leaves some of the other bigger specialist players - TIBCO, SoftwareAG (and to a lesser extent Progress and Red Hat) in an interesting position. On the one hand they will be more attractive, particularly for SOA and BPM, to customers looking for an application-independent infrastructure offering.
Software AG has gone to a potential competitor for the mantle of best-of-breed, specialist alternative to the likes of IBM, Microsoft and Oracle. If you had told me on Friday that Software AG was going to strike an OEM deal for SOA management and monitoring I'd have put my money on AmberPoint, which has historically been the OEM of choice for the likes of BEA and TIBCO.
I am not quite sure what to make of this decision. AmberPoint doesn't compete with Software AG directly and has established a healthy and growing customer base, as well as partnerships with some of the leading systems integrators - and a
technology partnership with Software AG! Software AG's decision comes not long after Oracle's decision to drop AmberPoint. As we pointed out in
our analysis of Oracle's roadmap for the BEA integration, we don't have any hard evidence for Oracle's claims that it had received negative feedback from BEA customers but it's something we will continue to explore. In light of the decision to go with Actional, it will be intriguing to see how the partnership evolves and how things pan out when Software AG and Progress are in a competitive situation.
This acquisition should be welcome news to Software AG customers that have invested in the company's SOA offerings as it will save them the time and effort of plugging the runtime governance gap that existed prior to the partnership. Those embarking on a significant SOA intiative should also give Software AG careful consideration, particularly if they are not wedded to one of the mega-platform providers.
Labels: AmberPoint, BEA, governance, ibm, Oracle, Progress, SOA, Software AG, TIBCO, webMethods
The lore of averages
I was chatting to a friend who's a top-notch Java developer over the weekend: we were shooting the breeze about Groovy, Rails, Spring, Hibernate and various other Things That Get People Excited (let's call them TTGPEs), and discussing how far they were likely to penetrate into your average IT shop. "Why do so many people insist on following the J2EE application model and associated patterns so slavishly," said my friend, "when they're so plainly not the right tool for the job in so many scenarios?"
"The thing that you never get from reading development books," I said - he'd just finished showing me a book on Groovy - "is how difficult it can be for your average IT shop to get on board with a new development technology, when you take commercial considerations into account. You can see from looking at code samples that language A is more compact or give you more productivity than language B. But what you can't see is the bigger picture of costs and risks."
I remembered a post of Steve Jones' I'd seen a couple of months back about
development as a discipline for the masses - and also
this one from Jeff Schneider about the value of SOA governance.
You see, the problem for your average IT shop in taking on TTGPEs is that even when they have been demonstrated to save time and/or money, there are two real barriers to adoption. Both barriers exist primarily because these shops have no option but to see development resources as a commodity.
First, within an average IT shop - think of one within a small utility provider or a local government - the business can't make a case for paying top whack to hire the very best developers. So, they have to shoot for the "mass market" of developers - hopefully capable and dependable, but not likely to be stellar performers. They also don't have a lot of time or money available for recruiting, so they tend to minimise the complexity of interviewing as far as possible - asking for "industry standard", well-recognised skills. Unless they can find TTGPE skills within that "mass market", they're not going to consider bringing those skills into the organisation. J2EE skills are now mass-market skills. Groovy skills aren't (yet).
Second, within such an IT shop, work tends to follow those same "industry standards", because the risk of doing TTGPEs is that if people leave or get sick, and new people have to be brought in, they have to be able to get new resources up-and-running quickly. If new staff have to spend weeks or months trying to re-engineer glamorous but unknown technology before they can continue a project, that's a huge, ugly cost.
Regardless of whether J2EE is increasingly being revealed to be more like a VW crossed with a tractor than a Ferrari, then, the truth is that most people have little choice, for now, but to stick with it and make the best of things.
Labels: 4GL redux, development, governance, industry
HP tightens up its SOA governance proposition
HP yesterday
announced long-awaited (at least as far as we are concerned) enhancements to its SOA software and services, which see the company beginning to realise the potential of its acquisition of Systinet (via Mercury) when it comes to SOA governance. Back in March, the other Neil
highlighted that lifecycle management is one of the four key elements of an SOA functionality pyramid and is:
all about supporting development, integration and operations teams in linking their efforts to ensure that the consumer service experience is high-quality and consistent under potentially unpredictable circumstances. Typically the foundation of this capability is some kind of registry/repository, but ideally tools go further than this - firstly by helping to automate team workflows for implementing quality controls at design time; and secondly by helping to translate design intentions relating to operational SLAs into runtime policies which are tied into the infrastructure.
HP is attempting to go that bit further by more tightly integrating the registry/respository capabilities it acquired with Systinet to the policy-based management and monitoring capabilities of its SOA Manager product. Whilst HP also brings other valuable functionality to fill out the SOA pyramid, including business process monitoring (HP Process Insight), security and identity management (HP Select Access) and synthetic transaction monitoring and reporting (HP Business Availability Center) it does not - and nor would it claim to - have everything.
Enter the Governance Interoperability Framework (GIF) it inherited from Systinet. The GIF is designed to facilitate information exchange with the Systinet Registry and Repository allowing third parties to integrate relevant technologies, such as policy enforcement and service orchestration, with the SOA lifecycle management capabilities. As well as announcing 10 new GIF partners, HP is also publishing the GIF specifications.
Integration is not totally reliant on GIF though. Systinet's registry is also embedded in the SOA infrastructure offerings from the likes of BEA, Oracle and TIBCO, which makes HP an obvious potential source of broader SOA lifecycle management functionality for their customers. The company is not such an obvious choice for customers of IBM and Software AG who are building out their own capabilities.
SOA platforms do not begin and end with BEA, IBM, Oracle, Software AG and TIBCO though. There are other choices: Microsoft, Progress, Red Hat and SAP etc. Not forgetting of course that organisations will be acquiring service oriented solutions as part of business applications. What's the story there? There are two. The first is GIF. The second is the HP SOA Registry Foundation that also formed part of yesterday's announcement and which the company describes as
a new software product expressly designed for independent software vendors. HP SOA Registry Foundation is a powerful, standards-based way to publish, categorize and discover SOA services and artifacts. This new product can be easily embedded with packaged applications and distributed solutions.
In other words, it's an OEM-specific version of the registry designed to allow HP to replicate the BEA, Oracle and TIBCO agreements.
Coupled with the HP's services capabilities, these announcements should mean that HP is able to exploit its systems management heritage and installed base to position itself as a credible SOA lifecycle management provider to organisations moving beyond project-level SOA initiatives - and to the software vendors that are helping them on that journey.
Labels: governance, HP, service, SOA, UDDI
Who do you put in a Centre of Excellence?
I've lost count of the number of times I've seen throwaway comments exhorting companies to "create a centre of excellence (CoE" (mostly, for initiatives like SOA or BPM). Vendor / pundit / analyst / journalist: "Having trouble? Establish a centre of excellence!" Customer: "Oh, that's OK then, I'll do that."
But let's take a deeper look. Quite aside from the role that one of these beasts plays (something I'll attack in a future post), what does a best practice CoE look like?
From what I've seen out there in real-world implementations of SOA and BPM initiatives, I suspect that the best results come from having a good mix of responsibilities / personalities in the group. Something like an even distribution across this matrix of perspectives:
Although it's tempting to staff a CoE with good dependable technical people that you understand, you need a good mix of business-focused types and technology-focused types, because those business-focused types will help keep expectations practical, and help keep business people from outside the CoE engaged and willing to help. And it's vital to get a good mix of practical and visionary focus, because rolling out new concepts and approaches to delivering IT capabilities requires both "selling" and getting things done.
That's my view. What do you think?
Labels: BPM, governance, SOA
Rethinking IT projects? Think service, not product, focus
I've read a number of articles and thought pieces recently that explore the problems with approaches to IT delivery that focus too much on projects as the organising concept - particularly when it comes to SOA adoption. The shortcomings of an overly project-focused approach are something I can agree with wholeheartedly. The research we conducted for
The Technology Garden (Wiley, 2007) convinced me that driving IT delivery using a project-focused organising principle is one of the worst things you can do if you want to try and increase the business value delivered from IT investments.
But if projects are
passé, what should they be replaced with? Most of the commentary I've seen suggests that a better approach is to think as if you're developing commercial software products. The excellent Todd Biske has one such piece
here.
You have to be think carefully before diving deeply into a product management mentality, though. The trouble is that taking too literal a view of IT delivery through the lens of product management can prevent you from reflecting reality the way that "customers" (regular business people in your organisation, and quite possibly those external customers that ultimately pay all the salaries) see it.
Why? Because software products have no business value, no matter how well-managed the processes to create them were. Business value only comes when you implement a software product and get business results. A shrink-wrapped DVD by itself doesn't get you any results, only a coaster for your coffee cup. Electronic software delivery doesn't even get you a coaster - it just fills up your hard disks with useless ones and zeroes.
You have to wrap all kinds of IT services - install and config, integration, customisation, training, administration, user support and so on - to turn a product into something that delivers real business value to real business people. The interface that regular business people have with IT isn't with products, it's with IT services. Even Microsoft, the ultimate software shrink-wrapper, has realised that enterprise customers don't buy products, they buy outcomes (see
this old post for info).
That's why the only way to deliver sustainable improvements in business value delivery is recognising that for the customers of IT organisations, "service is king", and starting to organise IT delivery around that. The first obstacle to overcome is to find ways of bridging the incredibly harmful divide that so often separates software development teams from IT operations teams.
If you take too much of a product management centric view, the danger is that you focus all your energy creating the right kind of development and deployment capabilities, without thinking of the broader service experience that customers need and expect over the lifecycle of a long-term commitment. IT operations is where the rubber meets the road, and where customer expectations are met or dashed. Too simplistic a focus on product-style management for IT delivery perpetuates the development-operations divide and squanders a great opportunity.
Labels: governance, inside-out IT, sustainability
Getting the right focus for IT governance
I've long been a fan of Nick Malik's
blog - and indeed it was his blog that led me to ask him if he'd be happy to be interviewed for
our book on IT-business alignment.
In this post Nick nails quite a few aspects of IT governance, and explains how they fit in the context of embarking on an SOA initiative.
Nick correctly calls out the dual roles of governance: not only in directing work so that things are "done right"; but also in directing work so that we "do the right things". The former area is the one where IT departments are most comfortable: you can focus on getting things right while retaining a very internal IT perspective. Doing the latter and focusing on doing the right things requires another set of skills and commitments that are less familiar to most.
It's easy to look at governance as Nick outlines it (and as many others do too, including us in our book) and say "hmm, this looks like a pretty heavyweight overhead to me. If I'm going to have to make significant extra investment in this governance stuff, how can I make the case for it?"
The key point here is that one of the things that makes IT governance "good" is fitness for purpose. Governance doesn't have to entail masses of documentation, full-time headcount, onerous processes and big technology investments. As Nick implies, a key feature of governance work is agreeing a strategic destination and a set of navigation charts.
In this context, your focus shouldn't be securing headcount and defining processes: it should be on securing agreements and commitments from people to work together.
Labels: book, governance
Swimming against the tide
Nick Malik
poses an interesting question here - are we making things difficult for ourselves by calling Enterprise Architecture Enterprise Architecture? His point is (if I've got it right) that architecture work is kind of crunchy, focusing on very well-bounded and defined outputs - whereas EA work is delivered within a different context. Enterprises morph over time, and enterprise activity can't be controlled or designed in the way that a specific project can. EA teams don't (or shouldn't) define things with hard boundaries: they should attempt to influence growth and change. In the context of our
book, our take here would be that EA is much more like garden planning than it is like cathedral design. As any gardener will tell you, unlike cathedral design, gardening is not a one-shot activity.
Moreover Nick echoes many others in calling out that EA work is often compared to city planning - and that city planners (or other similar types of entities) don't describe their work as "architecture". He has a great point - ideally EA shouldn't be called EA. It is a kind of discovery, planning, policy-setting and policy-enforcement practice - I'm even tempted to talk about it as a governance-like thing.
However we're hampered in this (as in so much else in the world of IT and business) because the language in this area has already been claimed. It will take a big effort to change the conversation.
Before we can do that, we have to settle on a term that makes sense and reflects reality, and this I think is the biggest challenge. Inertia is a powerful thing (how often do we change our personal banking provider, even though we're frequently told how important it is to consider?).
So - if not EA, then what?
Labels: EA, governance, language
Policy interoperability - a step in the right direction
At the end of last week a webMethods'
press release popped into my inbox highlighting a recent demonstration of interoperability between the company's UDDI-based registry (
acquired with Infravio), HP's
Systinet registry and one of Layer 7 Technologies'
SecureSpan XML appliances. In a nutshell, the three companies showed how policies attached to services in a UDDI registry (using the Web Services Policy 1.5 Framework and Attachment candidate standard specification) can be exchanged with Layer 7's appliance for policy enforcement.
Prasad Yendluri of the Office of the CTO at webMethods had this to say:
greatly enhance[
s]
the interoperability of all of the components used to achieve policy-based governance
a point which was reinforced by Toufic Boubez, CTO of Layer 7 who claimed such interoperability provides:
a powerful standards-based solution for overall SOA management and governanceHere at MWD we certainly agree that a policy-based approach is essential for effective management of the service lifecycle. Policies should capture and enforce the obligations and expectations of service providers and consumers represented in service contracts to maximise the quality of the service experience. Interoperability of policies is also essential, given the variety of
service infrastructure technologies required to support any significant SOA initiative. However, as I pointed out
over a year ago:
WS-Policy does not deal with semantics: it provides a framework within which those semantics can be defined. Support for WS-Policy provides no guarantee that the way one vendor defines a particular policy can be interpreted and enforced effectively by another. That will require agreement on semantics.For these reasons, I doubt that the three participants simply installed the products, created some services and policies and then demonstrated policy enforcement: they first had to agree how the policies would be represented in WS-Policy.
Don't get me wrong: I think this is a positive step in the right direction. However, it's important for those involved in SOA initiatives to recognise, as I pointed out last year, that a number of significant steps still have to be taken to reach the semantic interoperability goal that's required:
It's not going to be easy! It will require the participation and cooperation of vendors of all shapes and sizes. Vendors, moreover, who are going to have to relinquish the control that ownership of policy definition can provide.
Labels: governance, HP, Layer7, policy, SOA, UDDI, webMethods
A useful primer on SOA governance
I just came across this whitepaper from webMethods (who is not a client)
SOA Governance: Enabling Sustainable Success with SOA. Putting to one side the fact that this is from a vendor and the checklist in the Appendix is clearly oriented towards webMethods offerings - based on
the acquisition of Infravio earlier in the year - I have to say I am pretty impressed.
Too much of the discussion of SOA governance focuses on the design-time: adherence to standards, such as the WS-I profiles, schema validation etc. It ignores the fact that IT services, like services in the real world (think your mobile/cell phone service), are experienced by the customer, which is about more than just what is built by the provider. Because services are experienced, SOA governance must extend to the encompass the complete service lifecycle, from development through to operations: something which is acknowledged in the webMethods paper.
That being said, I do have a couple of quibbles:
- Business involvement is called out during service change but not in the definition of the quality of service agreements, which comes across as the domain of the IT organisation. Business involvement is essential here to capture expectations and ensure that metrics are presented in a business-meaningful way
- Service contracts are highlighted in the discussion of the SLAs - "how well" a service is performed - but not in terms of the functionality provided by the service - the "what" - and the commercial aspects of service provision - the "how much". If an SOA approach is to really deliver business value then it must be possible for business and IT to establish some common ground in terms of service expectations and comprehensive service contracts, which encompass all of the aspects of those expectations, do that.
Bearing in mind those two important consderations, the paper is worth a few minutes (as are our reports on
SOA and
SOA quality management which provide our perspective on some of these issues).
Labels: governance, SOA
