LiteBytes from Lustratus Research

Building a realistic business case for OSS

Some proponents of Open Source Software can be their own worst enemies in the efforts to distance themselves from the traditional software license based vendor.  For instance I read in a recent article that two of the benefits of OSS were: 

“Never again will you fear the BSA (Business Software Alliance, not the Boy Scouts!) knocking on your door wanting to perform a software audit.  The BSA even takes out advertisements on Google search pages for and up to $200,000 reward a disgruntled ex-employee can receive for reporting your company to the BSA! That's quite a powerful motivator.”

And

“In the world of Open Source Software, if you can't wait on someone else's schedule for a new feature, then you add that feature yourself. What? You don't have programmers on staff? You can always outsource to a programming company and have them do it for you.”

To translate OSS is really great because you won’t get nailed for breach of licensing agreements and you can always write your own software.  Not exactly compelling arguments for any business case!

While there really are arguments for ”going OSS”, most firms will not take such a strategic move.  In most cases, OSS is used to solve specific problems – just like any other piece of software – not change the world.  And the business case covers the same territory as for closed source: a combination of technical evaluation and assessment of cost and business risk.  The second point is challenging only in that we are less familiar with evaluating OSS in this way - and isn't helped by over enthusiastic promoters of the OSS religon.

Ronan

SOA helps with flatter supply chains

One of the benefits of SOA that I keep banging on about is visibility, and I read a great article recently that showed how this can benefit companies that are transforming their supply chains. I thought it worth adding some background to the high-level claim that SOA really helps with flatter supply chains.

To recap, in traditional IT architectures, applications and programs execute a range of business functions 'under the covers', making it hard to see what is happening to individual process steps. The problem is that the IT assets are deployed on IT-oriented boundaries (programs) rather than business-related ones (business operations). In SOA, IT components are arranged into business services that correspond to distinct business operations or steps.

IT monitoring and management tools can see when different IT steps are called and executed, but in the traditional example this information is really only relevant to the IT department itself. It means little to a business analyst. However, in SOA this same information actually represents calling and executing business steps, giving a greatly improved level of business visibility. 

The referenced article discusses the problem facing many companies as they face the need to transform supply chains. The argument posed is that whereas in the past manufacturing has been located close to the customer, with just-in-time supply to minimize inventory levels, globalization is increasingly breaking this model and creating long, complex, flatter supply chains that cross country borders and have to deal with varying levels of regulation and management along the way. Optimizing these flatter chains requires a clearer visibility of what is happening where, throughout the extended business process. Collaboration is important too.

As a result, companies are turning to SOA to help with these problems. It provides a level of standardization, making it easier to get all parties collaborating, and most importantly it offers the improved business visibility that is required.

As a purely academic postscript, my eyes were really opened wide by a new spin on supply chain management that had never occurred to me. The article points out the challenges of having to work the supply chain 'in reverse' - that is, what to do when a customer sends the goods back! Ouch!

Steve

Putting the suit on Social Computing

I have previously written about the application of Web2.0 technologies to enterprise problems at a general level.  In the past, I have taken the view that the Web2.0 technologies may be of interest, but the enterprise application of the 'social computing' side of Web2.0 was still very immature: the general value of collaboration was clear but how it would be implemented and which pressing business problems it addressed were not.  This lack of maturity was reinforced by fighting talk from some Enterprise 2.0 proponents about changing the way enterprises work by up-ending hierarchies and claiming that when the "facebook generation" moves into the workforce all will be changed.

However, I think that the concept is now maturing as can be seen from announcements from both BEA and more recently Progress around what BEA calls Enterprise Social Computing  and Progress calls Socially Oriented Architectures.  What is promising is that both announcements focus on the application of social computing (and it's ability to enable fluid communication and information sharing) to solve business problems.  In the case of ESC (an acronyn to make any tech marketeer smile), the application is to the area of process improvement.  As my colleague, Steve Craggs explains in his new insight on ESC and SOA (which is free to download at the moment!): 

"If a company can understand a little more about how employees are solving their day-to-day work-related problems, it should become possible to establish best practices or carry out training to improve employee performance. The traditional approach to solving this problem is to engage an external business process re-engineering expert. However, these experts are both expensive and disruptive. In many cases, the best practice expertise is already there—it is just that it is un-communicated, locked in the heads of one or more expert employees."

And of course, it isn't a huge leap to realize that SOA is a fertile place to start using such an approach - as this requires a high degree of communications across organizational boundaries and involves tech-friendly staff more likely to adopt new concepts like ESC.

Ronan

User experience with mainframe SOA provides interesting pointers

Yesterday, I had the pleasure to host an Integration Consortium webinar on the topic of mainframe SOA. The user experiences were provided by SunTrust, a major US bank, and I found them most illuminating.

One point that struck me was to do with ownership of the new services, from an organizational point of view. The issue here is that, although services representing mainframe transactions clearly fall into the domain of the mainframe programmer, the concepts of SOA and often the related tools can be quite alien to these programmers - having to worry about SOAP messages, XML, WSDL and web services standards for example. SunTrust cleverly selected a mainframe SOA toolset that masked much of this complexity, offering a development environment that COBOL programmers felt comfortable with. As a result, mainframe services are built and owned within the mainframe team, which is where they belong to be honest. To complete the picture, the tool transparently handles the service deployment, creating WSDL and exporting to UDDI registries as required, ensuring that SOA users will see familiar services.

The lesson seems to be, be clear on who you want to own what, and then choose a toolset that supports that decision. The alternative is a confused mishmash where no-one knows who is responsible for what.

Steve

IBM gets Cognos to fill the gaps

IBM has been on quite an acquisition spree of late, but the latest is perhaps the most predictable and potentially powerful. IBM is buying Cognos, the business intelligence and performance management vendor, for $5B. This has been on the cards for some time, and increased in likelihood when SAP acquired Business Objects recently - Cognos and Business Objects were acknowledged as the two leading players in the BI space.

This looks to be a great deal for both companies, and users should be pleased. With 25,000 customers spread across some of the largest companies in the world, Cognos is a well established BI player, and shares many customers with IBM. On top of this, with the SAP acquisition of Business Objects, Cognos was the last big pure-play BI vendor and a major target for acquisition, so its users must have had concerns over potential new masters - however they are likely to be very comfortable with IBM since it does not really have competing products and will therefore keep the technology alive and moving forward. From an IBM point of view, it will be particularly keen to get its hands on the 1000+ BI-experienced R&D team in Cognos. as well as the 2000 or so customer-facing field force.

The key here is that the two companies mesh really well together. IBM's Information on Demand initiatives have made every effort to ensure that data is accessible wherever and whenever it is needed, while Cognos concentrates on interpreting the data and generating business value from it. Combining the two promises to deliver even more accurate, timely and understandable information to support executive decision-making and business-driven data mining initiatives.

This also fills some gaps for IBM in its service-oriented architecture (SOA) strategy. At the moment, one of the few weak spots for IBM is its lack of an industry-leading BAM (Business Activity Monitoring) initiative. That is, IBM SOA can make programs visible in terms of business services, improving the propensity for getting a clearer understanding of business activity in IT operations, but it was not particularly good at interpreting the information in BAM terms. Now it will be able to deliver one of the best BAM solutions in the marketplace, making it possible not just to streamline and automate processes but also to continually improve their effectiveness.

If there is a challenge for IBM in absorbing Cognos, it is in the area of organization. IBM has made the decision to keep Cognos in its own business unit - BI and performance management. However, this unit lies within the IBM Information Management division. While this makes sense at one level, in that BI is very related to information, the performance management part is closely linked to the IBM SOA initiative driven from another division. It will be important for IBM to manage this carefully, but it is not the first time it has had to deal with this sort of cross-divisional issue - for example, it had to handle this when Tivoli, the management software company, was acquired.

All in all, this acquisition looks to be good for just about everyone - IBM users, Cognos users, IBM and Cognos companies and employees....but perhaps not for the competition!

Steve

Chasing SOA unicorns

I spotted an amusing analogy for the evolution of SOA programmes by Neal Ford in his blog: The perfect SOA is like a unicorn - a mythical beast - in the real world, we struggle to change our enterprise architectures from donkeys to horses.  To quote Neal:

"most company's enterprise architecture looks more like a broken-down donkey. The SOA experiment is to see how close you can get to a unicorn before you run out of money. Maybe you'll get to Shetland pony and stop. Or perhaps you'll make it all the way to a thoroughbred racehorse. There are even a few that'll create unicorns, but they are exceedingly rare."

Of course, there is nothing wrong with striving to create a unicorn - with the realistic expectation that your SOA will end up with something a lot better than a donkey but probably without a horn. 

Ronan

p.s. Myth experts will recall that unicorns can only be captured by the pure of heart.  Perhaps that is where the problem lies with SOA as well...

So what exactly is SOA governance?

If SOA is all the rage at the moment, then SOA Governance is the most frequently used term related to it as far as I can see. All the vendors, and many analysts, are talking about SOA Governance as the big issue, and tools are rapidly appearing to help with this governance issue.

I am wondering, however, if there may be an ulterior motive here. In business parlance, governance is an important word - it is definitely seen as more business than technical. So, is the word being hi-jacked by vendors keen to try to find yet another way to hook into the business world in order to secure the budget commitment to make product purchases? What is really meant by governance?

Governance seems to be all about defining expectations, controlling and granting powers, and measuring results. Funny that it is the root of the word Government, and a cynic might argue that these are three things that most Governments do NOT do well, but there you go. Anyway, in SOA tools terms this follows on to a number of different areas - project management tools / SLAs, security and management. Notice that these are implications at the tools level; some of the biggest aspects of governance are actually at the management process/procedure policy level.

If you now look at vendors claiming to play in the governance space, offerings typically fall into one or more of the following categories:

• Technical management tools - administration, systems monitoring, statistics
• Business management tools - SLAs, BAM, KPI management, dashboards
• Security tools - user authentication, authorization
• Project management tools - requirements management, policy enforcement
• Planning/education/training services to build the relevant knowledgebase and skills

In my view, the outcome of all of this is that it does not help to keep preaching about SOA governance, unless you offer answers to all these areas. I would find it much more helpful for vendors to say that they sell management tools, or business monitoring, or professional services, or project management assistance. The problem today is vendors are so desperate to hook into the business community that everything is lumped together as governance.

Is it any wonder users are confused about what they are being offered, and how it fits to what they want?

Steve