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.

Posted by nmacehiter in Software Lifecycle | Permalink | Comments (0) | TrackBacks (0)

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.

Posted by nmacehiter in Architecture • IT Governance • Software Lifecycle | Permalink | Comments (0) | TrackBacks (0)

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.

Posted by neilwarddutton in IT Governance • Software Lifecycle | Permalink | Comments (0) | TrackBacks (0)

I have just returned from a couple of days in Orlando, where I attended a Microsoft Server and Tools Business analyst summit which coincided with the company's TechEd conference. The RedMonkers James and Coté did a great job of live blogging the event (here, here, here, here, here and here) - and there was even some Twittering - but I needed the joys of a 9 hour transatlantic flight to collect my thoughts.

The big news at TechEd and the focus of the analyst summit was Microsoft's Dynamic IT for the People-Ready Business (Dynamic IT) strategy, which the company describes as building

on the company’s Dynamic Systems Initiative and ongoing Application Platform efforts to provide customers with the key areas of technical innovation necessary to make their IT and development organizations more strategic to the business

In other words it's a framework which builds on a number of Microsoft's most significant, but historically largely disconnected, initiatives which is designed to help customers understand how they can be combined to increase the business value of IT. This is long overdue, for a couple of reasons.

First, whilst Microsoft has used language in the past which implies linkage between the different initiatives and associated products, such as 'design for operations' for DSI and .NET, it's not always been clear how the implication becomes reality. For example, how do the System Center management tools exploit operational policy requirements defined in Visual Studio and how do those requirements map to policies defined in Windows Communication Foundation? Dynamic IT sets out to make the linkage explicit.

Second, Microsoft has lacked a cross-company vision for enterprise IT (for want of a better term) within which to frame discussions with customers and around which it can rally the troops. I'm thinking here of things like IBM's On Demand, HP's Business Technology, Oracle's Fusion etc. There's People-Ready of course but I think that's about more than Enterprise IT. Dynamic IT provides Microsoft with a competitive alternative and one that is more reflective of current reality than future aspiration.

There are four aspects to Dynamic IT where Microsoft plans to focus innovation:

* unified and virtualized
* process-led, model-driven
* service-enabled
* user-focused

built on a federated, interoperable and secure foundation. Obviously, it's still very early days but I do think Microsoft has a lot of work to do if it's going to achieve what I believe it hopes to with Dynamic IT.

For example, in his keynote when Bob Muglia talked about process-led, model-driven he discussed process-led in terms of the application lifecycle, BizTalk, Windows Workflow Foundation and Office Business Applications and model-driven in terms of System Center and IT management models (based on Service Modelling Language and the Common Model Library). What he didn't do was explain the relationship between the two. When describing service-enabled, he focussed on .NET, SOA, web services and software plus services, primarily from the bottom-up, developer perspective (consistent with Microsoft's initial foray into SOA) but failed to tie that into the end-to-end service lifecycle - Big SOA - and thus process-led, model-driven. (As an aside, I think Microsoft is also missing a trick when it comes to information and data as a service but that's for another day).

As well as explaining the relationships between the different aspects of Dynamic IT, Microsoft also has to be very careful that it doesn't fall back into the trap of using it simply as a framework for categorising its products. Increasingly, the key concerns of the people it is trying to reach with Dynamic IT don't fall into neat product categories and Microsoft has struggled in the past to articulate the joined-up propositions required to address these concerns because of its focus on product stovepipes (as I discussed here).

What I think Microsoft needs, as I explained during various meetings at the summit, are scenarios and associated case studies to bridge between the framework and the products and emphasise the linkage. This will also serve to highlight the importance of the three foundational aspects - federated, interoperable and secure - which might otherwise be lost and to tie into Core, Application Platform and Business Productivity Infrastructure Optimization roadmaps which Microsoft is using to help customers understand how they move forward from where they are today.

For Microsoft's customers and potential customers Dynamic IT is a positive sign that company is beginning to recognise that you are more concerned with the outcomes from deploying the company's technologies than you are about the technologies themselves or the way that Microsoft chooses to structure itself to develop and sell them. Over the coming months you should be looking to Microsoft to fill out the framework and seek explanations for how the pieces fit together today and how the company plans to enhance that integration going forward.

Posted by nmacehiter in Architecture • BPM • IT Service Management • Software Lifecycle | Permalink | Comments (0) | TrackBacks (0)

Who wouldn't want to be agile? The word itself suggests being lean, lithe, quick-footed, having all the moves and the instinct to use them. 'Agile' is hip, it's sexy, and unsurprisingly, ever since the term has been applied to software, it's had plenty of positive press both in the media and in the IT department.

Software methodology has always gone in waves, flip-flopping over time between structure and flexibility. So waterfalls gave way to spiral development models, and V-lifecycles faced off the new freedoms of Rapid Application Development, itself re-iterated as the more constrained Dynamic Systems Development Method. This cycle continues, with programmer’s programmer Kent Beck cutting the Gordian knot of convoluted software processes, slaying the dragon of overbearing management and picking up a lucrative publishing contract on his way down the mountain. Others have jumped on the 'agile and adaptive' bandwagon – indeed, some claim to have built it, how else would Mt Beck have got up the mountain?

It was ever, and it probably will ever be, thus. A good illustration of such thus-ness is the current debate around exactly what is agile development. More than once recently, I’ve heard the remark, “That’s not real agile.” For perfectly valid commercial reasons, of course, it is important to be seen as agile; equally, this can be upsetting to those who see their own, principled approaches being sullied by unscrupulous marketers. Indeed, the DSDM consortium is insisting that it is agile too (or indeed, “an enterprise-ready wrapper for agile practices”; “Nah, that’s not agile, its more adaptive,” others will say. How the winter evenings will fly by.)

Don’t get me wrong, I’m all for agile – whatever it is. But that’s an important ‘whatever’. It s quite easy for an organisation to say, “we’re agile,” However the reality could mean, “we’ve adopted the agile manifesto and its principles to the letter, and everyone in our dynamically organising teams can quote them from memory”; or equally, “we’re chaotic and we don’t want a formal development process so we’ve chucked a few trendy terms in the pot and we’re using them to fool our not-that bright IT management.” Even if the latter is not the case, how can businesses that had their fingers burned with RAD be sure that agility is delivering the goods?

Simply that, in fact – whether it’s delivering the goods. But what criteria to use for delivery? It is one thing to update a release of software, but quite another to make a positive difference to users. For commercial businesses and public organisations, the single criterion that makes any sense is, “does the delivery help the organisation in business value terms?” This can be couched in a whole variety of ways – user productivity for example, staff well-being and customer satisfaction – but again, all of these should be supporting the overall financial health of the organisation – either making or saving money – or they are missing the point: this is as true for public as private organisaitons.

The second factor involved in delivery however, involves the longer-term, sustainable benefits of any deployment. It is one thing for example to deliver the most basic of Web sites in ten days, which enables a company to start selling its products or reporting to its clients. As the company gets successful however, is the Web site going to keep up? Are the costs of any workarounds going to grow, such that in time, they outweigh the benefits? Will the increasingly demanding client base stop seeing the site as a useful tool, but more as a bottleneck? Everybody has their story of how the prototype became the production version – not the kind of early delivery that anyone would advocate, given the choice. If an organisation is going to deliver functionality early, not only does it need to add value at the start; also, later deliveries should work to shore up any kludges at the same time as adding to the functionality that’s already been deployed.

Agility doesn’t only exist within a project; it should also be present without. Perhaps the greatest test of agility of all, is the ability of a project to recognise when it is no longer able to add value, and has therefore reached the end of its useful life. Agile indeed, will be the developer who recognises his or her skills are no longer necessary on a project, and who is prepared to reskill or make themselves redundant as a result. It’ll take more than a methodology to tell them that.

Posted by joncollins in Software Lifecycle | Permalink | Comments (0) | TrackBacks (0)