There seem to be two worlds out there, the world of enterprise architecture and the world of SOA. The funny thing is that those in each world thinks that they can do the other world’s jobs.
He clamed that traditional EAs have not done a stellar job in understanding SOA opportunities, while the SOA folks have not figured out how SOA itself fits into enterprise architecture. The root of the dilemma is the fact that EAs are perceived in many organizations to be theoreticians who reside in ivory towers.
IT consultant Todd Biske of MometumSI, who was also at the conference, blogged in response that the onus would be on EA to make its artifacts more relevant to those on SOA’s front lines.
If EA can ensure that the artifacts it creates are consumable at the project level, then absolutely, SOA will be folded into EA. If EA is not creating artifacts that are consumable at the project level, then we have a problem.
And, according to EbizQ analyst Beth Gold-Berstein, who sat with Biske on a Future of SOA panel later in the day responded that SOA project teams have a lot to learn from EAs, noting that most current SOA implementations are architecture in name only.
She claimed that most web services today are data services that are, in essence, conventional remote procedure calls with web services interfaces. Using conventional RPCs, these rudimentary web services deliver none of the agility or reuse benefits that SOA could deliver.
We have a tendency to forget that the A in SOA is architecture, Linthicum noted. He added that many companies are managing SOA by magazine, meaning they want to buy or show that they are implementing the latest technology without giving any thought to the reality that SOA is actually a different way of architecting enterprise software that separates definition of the service from the platform or way that software is actually implemented.
That was a pretty tough challenge, explained Douglas Darner, enterprise architect for Chevron. Focusing on the interface, not the implementation, was a pretty difficult adjustment for the IT group. For instance, identifying the process of extracting data from upstream, wellhead production systems is used by numerous upstream applications. According to Darner, paying attention to information architecture was also critical.
Master data management is hard but critical to the success of SOA, he said. Most users tend to clean up data in Excel. If you leave it to them, you will get their own versions of the truth.
Our View
By and large, EAs as a group have only recently begun embracing SOA. For instance, many in this group still fear SOA as opening up the floodgates to enterprise IT assets in a manner that will be difficult to control. In effect, because SOA is supposed to make it easy, it would make it too easy to let software developers-turned-SOA project teams expose data and application functions in much the same way taking the familiar shortcuts to turning out quick results without concern for how their programs could be maintained in the long run.
For instance, CapGemini global CTO Andy Mulholland, a fellow speaker, claimed that many EAs still view SOA and Web 2.0 mashups with the same horror that their predecessors greeted PCs back in the 80s: as threats to the central order of things. In this case, there is the fear that SOA will make it even easier to expose enterprise IT and data assets, that could very well fly in the face of enterprise best practices for managing the software lifecycle, standards for software platform choices, and of course, compliance with regulatory mandates.
But there was one other point that Linthicum and other speakers pointed to regarding benefits of SOA: While IT organizations initially justify SOA projects because of the possibility of reuse, the true benefit to the business is not the savings from reuse, but the possibilities brought on because SOA can enable agility.
