Weaving an Infrastructure Fabric – BEAWorld 2007 Report
Like many of my analyst colleagues, I was invited to attend the BEAWorld 2007 conference in Barcelona last week. So what am I going to say, that has not already been covered by David Tebbutt (BEA struts its stuff) and Dale Vile (BEA: The death of packaged applications revisited?). Well if you remember my third article on BEA (Events and Edges – Understanding BEA (part 3)), my parting comment was “On the negative side, I don’t see a lot of partner activity based upon their solutions. This is a surprise as during their early years BEA made a big play in the channel. Perhaps I will see more at BEAWorld in Barcelona in October.”
Back in September 2007, BEA announced Project Genesis. This project carries all the current buzzwords in computing – social computing – SOA – BPM – virtualisation – into a single vision for the future. It was Paul Patrick, BEA’s Chief Architect who talked to all of the analyst community to explain Genesis. Patrick described the need for IT Infrastructure today to be like a fabric – woven not static, so that it is easier to change. Like many other IT people trying to create an analogy for architecture building, Patrick used the metaphor of building, equating the building of a single building to building an application and building a city to building a service. This, I have heard many times, but now came the difference; Patrick went on to say that cities are not homogeneous entities but are made up of Neighbourhoods! Neighbourhoods share some services but each has their own character – wasn’t this the great design plan for the UK new city of Milton Keynes!!!! – but there are local differences and exceptions. Patrick’s assertion is that actual the way SOA is working is that organisations are not building big pictures for cities, but are actually implementing by business process or organisational area. Therefore the need for IT infrastructure to be like a fabric, which is woven in layers, and able to work just like we currently use the internet.
So how is BEA going to deliver to us this infrastructure fabric? Well BEA sees there being 4 layers of infrastructure software that are needed:
- Hosting
- Service network
- Business process
- User interaction.
Hosting Layer
The Hosting layer is the rock upon which software as a Service can be delivered, as well being able to support organisations who wish to work in a stand-alone way. BEA recognises that they need to be able to support more than just a Java container, so they see a need to support for instance a .NET container. Another important piece of this layer of the fabric is Virtualization. Guy Churchward, BEA’s VP for WebLogic gave a keynote just on this topic. He stated that even with Virtualization today, each piece of software still needs maintenance and management and that there are redundant copies of the operating system and software produce which reduce efficiency. To overcome this issue, BEA has worked on the concept of “software appliances”. BEA has introduced “Liquid VM”, which is a virtualized Java container without the operating system that sits on top of the Hypervisor. This is the technology that has been implemented in BEA WebLogic Server Virtual Edition.
To complete the hosting layer, there is a need for unified management so that a distributed provisioning base can be used to manage distributed deployment. Churchward in his presentation on Virtualization, ended on a new product due for release in December 2007, called Liquid Operation Control (for those of you who like TLAs – LOC!), which supports the management of the virtualised environments. The last piece of the Hosting Layer is unified Security – need one say more.
Service Network Layer
The Service Network Layer has to be able to support dynamic discovery over the internet of services. BEA recognises that there is need to support both dynamic and static binding of services. The piece I liked was that this layer would also recognise the concept of Service Level Agreements (SLAs) around the provision and use of services. What was not mentioned during Patrick’s presentation was which standard BEA would use for this – at one time this was one of the concepts of ebXML, but the standards world produces so many overlapping standards it is hard to keep up!!! This layer is also were resilience needs to be defined.
Business Process Layer
This layer supports the definition of the business logic both in terms of the processes and the rules. It requires monitoring and dashboard capabilities. Most of this layer, BEA already have supported in their Current BPM product set – AquaLogic Server. However one of the drawbacks here is that BEA actual have a number of what at first hand are overlapping products – AquaLogic BPM, WebLogic Event Server, WebLogic Real Time Server and WebLogic RFID Server (and you could include WebLogic Integration Server). This plethora of products is very IBM-like and makes it hard for a user to understand what they want – as well as potentially expensive!!
Gwen Durrill, BEA’s Unit Exec WebLogic Time and Event Driven products, explained; “We have a much clearer product strategy than IBM. WebLogic Event Server, Real-time and RFID all fit under the Time and Event Driven Computing family. The Event Server processes high volume streaming events and applies Complex Event Processing rules to the streaming events. WebLogic Real-time provides a low latency JVM. WebLogic RFID provides the complete infrastructure to deal with enterprise RFID including events from the edge of the network. Real-time and RFID all form part of the “core foundation” layer that sits “underneath” Business Process Management. An event in the Event Server or the scanning of an RFID tag might cause a process in the Business Process Layer to be started or resumed but they do not work at the same layer in any way.. If a customer is only interested in business process management, than all they need is AquaLogic BPM. All the products work on their own and do their own very specific job.” It would be an interesting exercise to create Venn diagram to see the overlaps between these products. I raised this point with
User Interaction Layer
This layer is about supporting the presentation logic. Patrick talked about the need for this layer to support the use of different devices from mobile phones to kiosks and pc’s and even to RFID tags and other event driven devices. The layer also has to be able to adapt to different roles that might be played by the same individual in an organisation. The last adaptive quality need was to be change with context. This layer has to be able to be support user modification and even self-learning.
Of course the big buzzword is Social Computing and this is at the heart of this layer. Mark Carges, BEA’s Executive VP for the Business Interaction Division gave a keynote on BEA’s vision for Social Computing. He described how in organisations today information and business processes flow between organisational silos. These silos create gaps, and organisations survive these gaps by using personal productivity tools, such as email, IM, portals and mobile phones. BEA’s vision is to produce a social computing environment based on Web 2.0 that uses participant driven collaboration tools and allows the assembly of mash-ups to support user’s view of information. For more details please see Social Computing – understanding BEA (part 4).
Conclusion
So you now have the story and a view of Project Genesis. If you have read the blogs of Tebbut and Vile you will have seen their view of the story. So what is it that I don’t see? The answer is simple – PARTNERS.
If this fluid woven fabric infrastructure architecture is to take off it not only needs System Integrators like HP and CapGemini to commit, but it really needs ISV’s – the people who build applications. Now in the keynote of Alfred Chuang, BEA’s Founder, the proposition was that organisations no longer want package applications, they want “Dynamic Business Applications”. I think this is too-generalised and narrow minded. From my experience in the manufacturing and engineering sector, organisation have chosen to go the package software route as the majority of best practice processes are incorporated in the SAP’,s Oracle’s and Infor’s and for supply chain in the Manhattan’s, Red Prairie’s and I2’s of this world. They want something that works with the minimum of fuss – it is the SIs who have added complexity by tailoring everything in sight so that they can make their money. What most organisations are looking for is the ability to develop or tailor those parts of their business processes where they want to differentiate themselves. It is in this latter area I can really see the need for an environment that allows organisations to support their business processes in a SOA way based upon the purchase of package solutions that cater for the processes that common in various sectors – for instance do organisations compete or differentiate them over the way they handle their finances. Answer in 99% of the time is no.
So there I was in Barcelona looking for ISV partners who are going to stand up can support this message. Did I see one? Did I miss them in the darkness of the presentation room? Were they outside in the exhibition hall or there as sponsors of the event? Not really. The Platinum Sponsors were HP (SI) and vmware (infrastructure). The Gold Sponsors were CA for their wily technology (Infrastructure), Indra (SI), Accenture (SI), Intel (Chips and Services), Sun (Hardware) and Quest Software (Infrastructure). The silver sponsors were Competence (Infrastructure), Adobe (Office and Dev) and soaapps.com (Service provider for apps). Talking to Pam Crane, BEA’s AR Director, I discovered that BEA had held a 2 day conference for ISV partners before we analysts arrived. During those 2 days, BEA had spent time describing how the micro services strategy could eb exploited by the ISV community.
Mike Piech, BEA’s Senior Director of Product Marketing, Tuxedo and WebLogic, explained to me that the ISV part of the Genesis will come out at the end of the year. So my message to BEA is like the architecture, like the concept, but make sure that the ISV announcement in December stacks up, as it is your indirect channel and particularly your ISVs, that will make or break this vision.