Why Enterprise Architecture is a Joke

Enterprise Architecture is a joke. And I don't say that lightly. My goal isn't to pick fights with enterprise architects - quite the contrary. I've got huge bets on EA - my time - my career - my money. My goal is to improve it.

Anyone who has been in our industry for any period of time has heard the jokes about EA... "EA's are the guys who program in PowerPoint." Despite valiant efforts to mature the discipline by groups like IASA, the OMB, The Open Group, The Zachman Institute as well as individuals like Ambler, the discipline remains fragmented and often unproductive.

In my opinion, there are several reasons why the discipline has not matured more quickly:

1. Zachman pioneered, than stagnated. I believe that the single largest reason that EA is a joke can be linked back to the pioneer. This pains me to say, but many in our industry were patiently waiting for better stuff to come from Zachman and it just didn't happen.

2. Bad Application Architects got promoted to be bad Enterprise Architects. Although this isn't a universal truth, I've witnessed my fair share of it. Those who can't architect do PowerPoint.

3. Silo Organizations promote Silo Funding. Many EA's never had a chance. They live in organizations that fund everything according to business silo's. Then, the EA is expected to bridge the silos with nickle and dime funding. Their inability to perform Herculean change (multi-channel, master data, cross-organizational BPM, master SOA services) has many of them designated as cops with no gun, just a good flashlight.

4. The Tooling Sucks. Modern EA tooling is complete pile of crap. It is designed and written by a generation who is out of touch with the needs of modern I.T. groups.

5. Unconnected Models. Expanding on #4, our models (and tools) do not sufficiently flow from one model to the next. Software development is often explained as a series of model transformations from concept to design to construction, where each stage adds additional fidelity. We currently have a huge hole between EA and the downstream constituents.

Today's enterprise architects have been given the equivalent tooling as programmers in the 1960's. I feel like I'm bashing developers who were handed punch-cards, told to program in assembler and then scolded for their lack of productivity.

The good news is that most EA's are providing significant value despite their handicaps. The great news is that smart people have identified the problem and are actively working on the solution.

Key WOA Concepts

Nick Gall clarifies a few key concepts of web architecture around the URI:

---

On Thu, May 1, 2008 at 9:09 AM, Gregg Wonderly wrote:
> I think that there are two distinct uses of URIs. There are URIs that are never
> intended to be typed by people (or at least don't need to be), and there are
> URIs that only people will type.

I couldn't disagree more strongly. We should be doing everything in our power to eliminate the distinction between human understandable and machine understandable interfaces. Thus suggesting URIs for humans be different from URIs for machines is a step in the wrong direction.

There are three important reasons to make interfaces for humans and machines as similar as possible:

Debugging: you never know when a person needs to look under the covers to see what's going wrong. Why do you think the Internet and Web emphasize ASCII text-based protocols even though they are far less efficient than binary and will rarely be seen by most people

"Show source": human readable interfaces generally and human readable URLs specifically make it easier for developers (and even occasional scripters like me) to learn from one another

Serendipity: TBL and RTF emphasize that the web is designed/engineering for serendipity. Thus you never know (and shouldn't try to guess) which URIs people will or won't want to use directly.

Our goal should be to minimize the distance between UI and API. Assuming that people will see and use all URIs is a big step in that direction.
-- Nick

---

Spot on, Nick! I love the notion of 'minimizing the distance between UI and API'...

See: http://tech.groups.yahoo.com/group/service-orientated-architecture/message/10245

SOA Acquisitions List

I've updated the list of SOA Acquisitions:
http://www.momentumsi.com/SOA_Acquisitions.html


The new transactions were:
- Cape Clear to WorkDay
- LogicLibrary to SOA Software

I also added Sonoa Systems as a new target.

SOA Software Acquires LogicLibrary

Today, SOA Software announced the acquisition of LogicLibrary, a leading provider of software asset & reuse management. The terms of the acquisition were not disclosed.

SOA Software is best know for their integrated SOA Governance platform. The key word here being "integrated". SOA Software has both design time and run time platforms that share policy information seamlessly. For anyone who has felt the pain of integrating stand-alone registries and repositories with policy enforcement points, mediation points and web service management tools, you'll appreciate the beauty of having an integrated solution.

SOA Software is realizing a grand vision: unified governance and management of SOA across the Enterprise Lifecycle. The acquisition of LogicLibrary will give them significant depth in managing design and development assets. LogicLibrary has deep integration in IDE's and SCM's. In addition, it extends their reach into enterprise architecture by capturing reference architectures and development policies.

Through this acquisition, SOA Software is demonstrating the depth and breadth of their vision. At this point, it is unclear if the competition fails to see the vision or merely fails to execute on the vision. Regardless, SOA Software has raised the bar (again) before many of the competitors have caught up with the last bar-raising that they performed.

SOA and WOA Comparison

Several peopled (too many to name) have recently compared SOA and WOA. Unfortunately, virtually all of the comparisons are really more of an analysis of 'Web Services vs. REST/POX/RSS/AJAX'. For those of us who 'do SOA' for a living, this drives us crazy. We fought for years to get people to quit thinking about SOA and Web Services as being the same thing. Now we have both analysts and press undoing the progress that we had made. Ugh.

Ok guys - steal this:



Please consider extending this little framework as a way to do proper comparisons. If you feel the need to add rows, I encourage it. If you don't like the contents of a cell - change it, but for the love of God, please quit comparing Web Services and REST and calling it "SOA versus WOA".


As for the cute one liners: "WOA is the SOA that works"... "SOA is the internal cloud" :-) You guys kill me. This is excellent nonsensical dribble.

However, the idea of 'building your WOA on your SOA' caught my attention. My deciphering of this statement is "use the EA & Governance practices to ensure business alignment, proper sharing and quality while also using lightweight protocols to drive barrier-free consumption and composition." Assuming this is what was meant... I'd agree! Perhaps another post on this subject...

Targeted Markets for PaaS Providers

Yesterday I wrote that the Google PaaS offering was not suited for the Enterprise primarily due to the language of choice (Python). This had me scratching my head. The people at Google aren't stupid - they know where the money is... why would they make this decision. And then it occurred to me.

Google is betting that the Enterprise will spend more money on SaaS than they will on PaaS. As Gartner said,

“Ease of use, rapid deployment, limited upfront investment in capital and staffing, plus a reduction in software management responsibility all make SaaS a desirable alternative to many on-premises solutions, and they will continue to act as drivers of growth.”

Google has made a bet that they can lure start up companies and next generation developers to their platform by choosing a dynamic language that facilitates mash-ups. And by doing this they will be the preferred platform for many next generation SaaS companies. But which ones?

The Google platform doesn't really offer any 'enterprise grade' functions. What it does offer is simple access to the Google world of social networking, ads, etc. In its current form the platform is best suited as a platform to enable SaaS for large audience applications (like social networking).

PaaS providers are still trying to figure out their target markets. Companies like Coghead are chasing the SMB market, hoping to attract customers who want to avoid setting up their own hardware and paying expensive programmers. SalesForce is clearly going after the enterprise ISV's. We're quickly getting to the point where each of these players will have to announce their target market to the world. The 'one size fits all' model won't last.

Enterprise PaaS

The recent PaaS announcements from Google and Amazon have grabbed the attention of the enterprise customer. Utility computing, clouds, pre-integrated platforms and business services are all sexy topics. But these same companies also realize that there are huge hurdles to adopting these concepts. They're big ships - and they don't turn easily.

How do I get PaaS?
Companies will ask how they can take advantage of this incredibly disruptive computing phase. I'm in agreement with Michael Nygard who feels that "everyone will want one". See:
http://www.michaelnygard.com/blog/2008/02/a_cloud_for_everyone_1.html

Michael discusses the typical progression of high tech products:

1. Very expensive. Only a few exist in the world. They are heavily time-shared, and usually oversubscribed.
   
2. Within the reach of institutions and corporations, but not individuals. The organization wants to maximize utilization.
   
3. Corporations own many, as productivity enhancers, some wealthy or forward-looking individuals own one. Families time share theirs.
   
4. Virtually everyone has one. To lack one is to fall behind. No longer a competitive advantage, the lack of the technology puts one at a disadvantage.
   
5. Invisibility. Most people have or use several, but are not aware of it.

Michael goes on to say that he feels that Cloud Computing is currently at Stage 1 but it won't be long before large enterprises want their own. I'd argue that several enterprises already have their own cloud or utility computing environment. However, not many of them have a pre-integrated, platform sitting on the cloud ready for I.T. customers to use. There's a big difference between virtualized hardware and offering a software computing platform.

If you need to store data using the Amazon or Google offering, the options are clear. They have a couple services available - just grab the one you want and use it. To accomplish the same task in your average enterprise I.T. shop, you'd call up your enterprise architect, get a copy of the Technical Reference Model, identify the applicable elements, and then go to an infrastructure group to try and get them loaded so that you can test to see if they will work for their project. Ugh!

It will take a rebellion for enterprise I.T. to change but this act might be sooner than you think. Developers are already using Amazon and will quickly be messing with Google. They'll be telling management that they want to use this stuff because it is quick and easy to get going. (It's the same reason why people wanted off the mainframe and eventually ignited the client/server era).

In my opinion, Enterprise PaaS is inevitable. Organizations will not be able to switch to a purely outsourced model but will look for hybrid solutions, including creating their own PaaS. The PaaS model of the future will have to embrace multiple PaaS vendors (dare I say federated Paas). But, of course, the major infrastructure vendors will offer a PaaS-in-a-Box that mimics their own hosted model (think Oracle/BEA, IBM, SAP, Microsoft).

Who will win?
It's too early to say. Early indications are that it isn't Google. Their decision to go "Python-Only" is an extremely strong statement. Personally, I can't think of a single enterprise that considers Python part of their strategic computing platform (nor do they have armies of trained Python developers). The winner should be IBM, but they tend to think everything is a consulting problem. SAP isn't exactly known for their technology... Amazon has done some pretty cool stuff. Normally I would have discounted them, but who knows? Salesforce has an early lead but they don't have much of a footprint in the enterprise. Oracle/BEA and Microsoft both have interesting prospects in this space. If I were a betting man (which I am), I'd throw my chips on these guys.

Microsoft's 10 Year Old SOA Strategy

If you aren't familiar with Microsoft's SOA Strategy, I'll sum it up for you:

BizTalk + WCF + Vaporware = SOA

Yesterday, I attended a Microsoft SOA event to get briefed on their strategy. To say the least, I found myself disappointed. After 3 hours of showing slides and demo's I finally concluded that Microsoft's SOA efforts to date have been a failure.

At the heart of their strategy is BizTalk. It's the one SKU that they can actually sell that is related to SOA. And if you listen to Microsoft, you'll be told that virtually all SOA paths lead to BizTalk. If memory serves me, BizTalk was released in Beta in 1998 and became generally available in December of 2000. This isn't exactly a new SOA product.

Windows Communication Foundation (WCF) is a fairly new component that was introduced in the last couple years as a pluggable framework to enable the Web service protocols.

The third part of the equation is Oslo. This mythical beast is basically the next version of a bunch of products which will help build on the vision of Software Factories. Oslo will not be 'released' as a unit, but rather each individual product will get released on its own timeline.

Robert Wahbe, the Microsoft executive in charge of the Connected Systems vision, must either be sitting on some elaborate game plan which involves a well-kept secret to acquire some actual SOA products, or he's in serious trouble. It is clear that Microsoft no longer has the killer instinct that it had years ago. But even then, the lack of results in this area must stand out like a sore thumb.