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
|
