BEA, SOA, UML

I recently spent a few days at BEA’s eWorld conference. Customer after customer made it clear that Service Oriented Architecture (SOA) is for real and is a guiding principle behind efforts to rationalize IT software infrastructures. Such thinking closely resembles the current vogue for IT hardware simplification.

SOA essentially boils down to Architectural discipline. In amongst the hype about XML web services, the importance of UML for data and process modeling in SOA projects has been underplayed. But ask any enterprise architect about their SOA project and they will likely explain that end to end data and process modeling is essential in decoupling current monolithic architectures to support more flexible ways of working. A central tenet of SOA is reuse; could we reuse a single customer id, for example, across multiple applications, published as a service? The answer is yes. This is not to say that organizations can boil down software infrastructures to data singularity, with a single canonical data model across the entire company, but SOA is many respects is a set of methodologies rather than an end point.

XML Web Services may be a bottom up grassroots phenomenon, but SOA is top down; it must be driven into an organization against cultural, political and technical reaction.

SOA is all about rigor.

At eWorld a representative from the major US grocery store chain Albertsons – which this year will spend $500m on IT–explained that vendors are now put through far more rigorous evaluations before getting on the approved supplier list. Supplier numbers are being whittled down in favor of standard toolsets.

Perhaps most surprising is that DBAs and developers are being told what tools to use, in the context of an enterprise IT architecture. “The practitioner knows best” thinking is anathema to SOA; which requires standardization for efficiency. As the Albertsons representative explained–driving SOA will make you unpopular in the IT organization. Every administrator in the world thinks they are super productive and can only be productive with their preferred tools; DBAs are usually guilty of this kind of thinking. But this thinking must be broken down for SOA to succeed.

SOA is not a technology. It’s an approach. It’s not even new thinking per se–anyone remember CORBA, ITIL or remote procedure calls? But as an industry we have established some new best practices and XML-based standards that promise a better understanding of the balance between coarse grained and loose grained components and or business services, which will allow organizations to make their businesses more flexible under the SOA banner.

SOA is an approach that allows IT to regain control in the face of pressure of lines-of-business. Standards are set at the center. LOBs and developers MUST comply. LOBs have flexibility about the services they build or demand, but not the technology these services are instantiated in.

Meanwhile BEA has real customers adopting SOA and a strong argument that its products map well to SOA thinking. The likes of British Telecom, Covad Communications and Virgin are all using BEA software in an SOA context. Telecom is a service oriented industry, with products often comprising a number of services from different suppliers. Telecom is therefore more mature in its readiness for SOAs; its no coincidence that Corba became so well established in Telecom. If BEA can consolidate its beachhead in this sector, already its most lucrative and entrenched market, it will gain valuable expertise in building SOAs for other sectors.

BEA’s most recent financials were disappointing from a Wall Street perspective but the vendor is still strategic for the majority of its customers. Somebody has to provide an enterprise counterweight to keep IBM and Microsoft on their toes. BEA should benefit from current projects to whittle down preferred supplier list.

BEA should perhaps invest in UML tooling to support its efforts and buttress for competition against Oracle. The dark horse on the UML side remains Microsoft though; it claims that the uber-modelling approach of UML is doomed to failure, and that a more appropriate approach is to use domain specific modeling languages. We shall see—SOA is about breaking down domain distinctions, not building new ones. For now it seems practitioners are speaking up for UML.