LiteBytes from Lustratus Research

Beware of the OSS Trojan Horse

Open source software (OSS) seems a great idea, particularly for segments of the market like SOA where there are lots of standards - some would even say too many. After all, the software is free isn't it? Of course, in reality,the decision whether to go with an open source approach to SOA is a lot more complicated than that. The key thing when considering SOA is to be realistic about the business case, as discussed by Ronan in his recent post. Evaluating the value proposition for open source SOA is a non-trivial exercise. This is a subject that Ronan goes into in much greater detail in his recent Lustratus Report, "The open source value proposition for SOA", available from the Lustratus web store, where he considers a wide range of factors affecting the final decision.

One point that jumped out at me from the report related to the need to be sure that the chosen OSS solution is not a trojan horse. The problem is that some open source projects are actually being used as test-beds by commercial vendors, as a way of gaining valuable input and experience that can then be used as part of a future commercial offering. On the one hand, this can be attractive - after all, if a vendor is driving the project then it is likely that skilled resources will be available to ensure its vitality. But on the other hand, if the vendor plans a commercial offering then what functions will be reserved for the 'full function' offering? Will these be needed in the future? As Ronan states in the report,

"It is common with the larger vendors in particular to promote OSS as a light weight alternative to their full strength closed source products.  For these vendors, it is essential that due diligence verifies that the OSS solution will be sufficient for all current and future requirements.  If this is not the case, the cost of the closed source product must be factored into the business case."

This doesn't mean to say that these projects should be avoided - just that it is wise to consider the gifts the Greeks are bringing, and what's in it for them....

Steve

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

Meanwhile in a parallel universe, Micosoft announces its SOA modelling plans

Microsoft's project Oslo is both interesting and ambitious as a concept and a project.  As a concept, Microsoft is recognising the need for formal modelling - in particular for SOA - and as a project Oslo promises to provide formal modelling capabilities across a range of Microsoft products over the next couple of years. Unfortunately, the announcement also seems to reflect Microsoft's wish to live in a parallel universe of its own making.  This is unfortunate as such a parallel universe is fundamentally incompatible with SOA - which Oslo seeks to enable.

To focus for a moment on the positives: Oslo must be acknowledged as a major move from a vendor who up to now wouldn't touch any sort of modelling with a 10 foot pole.  While I certainly don't believe that model based approaches are perfect, standards such as UML when used appropriately and pragmatically can be very effective in the development process.  Given its previous position as sceptic, Microsoft is in a good position to deliver such a pragmatic and accessible solution and this appeared a first read to be its goal as quoted here:

"In the past a very select group of users has used modeling. Microsoft is going to make modeling mainstream for the average developer," said Martin. [Steven Martin, director of product management for Microsoft's Connected Systems Division]

To a great degree, Mr Martin is right:  Formal modelling tends to be used by only a minority and the learning curve and perception of complexity and cost put most off:  There is definitely an opportunity to make modelling more accessible to less technical and less modelling-aware developers.  However, rather than at least taking UML (the widely used and mature modelling standard) as its starting point, Microsoft has decided to go its own way and thus ignore much experience and knowledge of how to model systems built into this standard. 

Furthermore while aiming to be more democratic in its approach, Microsoft also appears to wish to entwine the modelling activity into its own technology stack.  This will inevitably result in a Microsoft only model which in turn will allow its customers to build only Microsoft dominated (if not exclusive) versions of SOA.  Which will be great for that minority of Microsoft exclusive shops and of little use for the rest of the world. 

As Oslo is still only at its earliest stage, perhaps Microsoft could reconsider its decision to ignore the standards and the heterogeneous world most of us live in ...  please

Ronan   

Open Source SOA - Are we there yet?

I am often asked whether open source (OSS) SOA is a reality yet - whether it is ready for prime-time, as they say. The answer, as is often the case, is 'It depends'. There are many OSS projects in the marketplace around ESBs, Integration and SOA, but just having a project in place is a long way from having production-ready software. For a start, there are the questions of maintenance, support and even indemnification against possible future legal activities. The most useful projects are those that have an associated commercial company addressing these types of areas.

However, the other aspect to consider is that most opern source projects are started and driven by technically adept programmers, so they tend to be oriented towards programmer usage. In SOA, this may be acceptable, depending on requirements, but it may also be desirable to have a solution more oriented to business analysts. They key is to be clear on what you want, and on what is being offered.

For a longer discussion on this topic, Lustratus has just published a free assessment of one particular OSS integration vendor, MuleSource, and its open source offering Mule. This paper considers a number of these types of key questions over OSS SOA, but of course in the MuleSource context.

Steve

Can you buy a SOA?

This is one of the classics of Service Oriented Architecture discussions and has recently resurfaced. Joe McKendrik over on his ZDnet blog rounds up some of the recent discussion. The heart of the issue is that SOA is not a product category because it is an architecture. Furthermore it is an architecture which requires significant focus around governance and organisation and therefore just selecting some products does not deliver SOA. Early on when SOA was close to synomious with Web Services, this was an important point to make: Just deploying a Web Services stack did not make what you did a SOA (giving rise to the delightful acronym JBOWS - Just a Bunch Of Web Services - to distinguish this approach from 'true' SOA).

However, from this entirely rational view grew the corollary that SOA can be implemented with anything. While theoretically this may be true, it can be taken to extremes: Clearly, the right product is bound to make it easier to implement SOA than the wrong product - even if you already own the wrong product. Also clear is the fact that you can buy important components of your SOA infrastructure from registries to management to ESBs. Furthermore, there is every reason to believe that software vendors will over time continue to move beyond 'just' providing infrastructure to providing larger chunks of SOA 'out of the box' - just as SAP et al do for ERP (as Jack van Hoof points out ).

Therefore today and in the future, SOA programmes must absolutely start at the architecture level and not simply select products. However, today and increasingly in the future it makes complete sense to use commercial (or Open source) software to ease the implementation:  SOA is othogonal to packaged software - not an alternative.

Ronan