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.

JBoGS and PoPS

I noticed that Nick Malik and others have stepped up the call to stamp out "JBoWS" (Just a Bunch of Web Services). Not me. After some soul searching, I've determined that JBoWs is the natural first step that an organization takes on the path to service orientation. It's not that it's right or wrong, it's just a stepping stone.

Since the industry likes buzzwords and acronyms, I'll add to the mix. It has been my observation that the next step is to take the 'wild' services and govern them. I've been calling this, 'JBoGS' or (Just a Bunch of Governed Services).


JBoGs is the natural extension of JBoWS. Services continue to be funded in a project (and often silo manner) but are designed, built and operated according to modern governance concepts. With JBoGS, a company will most likely have some type of registry / repository solution, lifecycle governance and runtime management infrastructure and practices in place.

This is an excellent step after JBoWS and it isn't too hard. People like to say, "You can't buy SOA". Well, that's true... but for the most part you can buy JBoGS. Moving from JBoWS to JBoGS requires some infrastructure, a SOA lifecycle and governance practices, all of which can be bought from vendors like MomentumSI, IBM, SOA Software and Progress.

JBoGs might sound like a derogatory term, but it isn't. I applaud the companies that are getting experience in building and governing services. But let's get real, that's not "SOA" - it's another stepping stone.

I'm throwing out another term: "Patches of Planned Services" (PoPS). Here, we're aligning the enterprise architecture with the Services. In essence, we're performing urban planning for communities of services. This is the 'planning' view of SOA typically thought of as a top-down approach. Notice that I used the word 'patches'; I didn't use a term like "Enterprise-Wide Planned Services" - the fact is, no one (who keeps their job) will do this across the enterprise. We'll cut up domains (or patches) and plan one area at a time.

The Evolution
We have several customers who are at the JBoGS stage right now. Most companies want to get their 'wild services' governed before they move to more ambitious goals. 2008 appears to be the start of the PoPS era. Companies that have matured their JBoGS are now looking for SOA to support business critical processes like order-to-cash. This means that they now have to roll out multiple services (not 1 or 2, like in JBoGS). This is the driving force for creating planned communities of services which are typically aligned to business processes. Finally, eh?

You'll notice that in the diagram above I imply that there is something after PoPS. There is - I know it, but the future remains cloudy. In the past, I've predicted things like: organizational alignment to SOA, alignment to business strategy, external service networks, and a host of other great ideas. Bottom line is that I don't know, and most likely no one else does either. Don't worry about it. For now, keep working on the other stepping stones!!!

SOA Acquisitions (updated)

I've updated the list...

http://www.momentumsi.com/SOA_Acquisitions.html

I have 16 companies still listed in the "producer" category (target companies). I'm guessing we'll see two more go in 90 days.

Facebook Terms

You probably saw where Scoble was temporarily suspended from Facebook. It made me go back and look at their legal terms. The one that threw me for a loop was:

You can not...
"use automated scripts to collect information from or otherwise interact with the Service or the Site;"

I must be missing something. How can a software platform like Facebook not allow "automated scripts to... interact with the Service or the Site"??

Just like moving from ISV to SaaS requires a change in attitude, so does the move from a 'web application' to a 'platform'.

Enterprise SaaS Must Stay Up

This is the kind of thing that gives me the hebejebees:

---

---

As soon as you start putting "production data" in a system, it must stay up. In this case, Spock clearly identifies that the system isn't 'Production', but is in 'Beta'. The difference between Beta and Production in SaaS is really just one of expectations. If Spock were to drop all of our data we'd be pretty upset; in my book that looks more like production than beta.

I want a SaaS provider to prove to me that they know how to add features without taking the system down. That is, even in beta, I expect the system to stay up. I expect that they'll do a behind the scenes data migration to make things right.

Balanced Views of SOA

I hate adding new terms, but I think we're hurting ourselves by constantly overloading the term SOA. IMHO, we would be better off if we formalized the "The Balanced Views of SOA". By "views" I'm referring to the old "4+1" type concept, see: http://tinyurl.com/2qed42 or http://tinyurl.com/2pmpmt

Premise: SOA is a collection of techniques which can be understood by observing a solution set from several different vantage points, or Views. The views can be divided into three primary categories:
1. Service Portfolio Views
2. Individual Service Views
3. Consumer-Service Views

The Service Portfolio Views focus on treating services as business assets residing in a portfolio. The role that most likely uses this view is the Enterprise Architect. Example views might include:
Business Priority View, Service Pipeline View, Process View, Portfolio Investment View, Consolidation/Rationalization View, Information Model, etc. These views help in the prioritization and planning process and to keep things organized (think Metropolis).

Individual Service Views focus on describing a single service. This view is most likely used by analysts, developers and testers to create a new service. Example views might include: Service Interface View, Service-Component View, Service-Deployment View, etc. Note that these views most closely resemble the traditional 4+1 concepts.

Consumer-Service Views focus on describing the relationship between services and the consumers (at plan-time, design-time, provision-time and run-time). The roles that would leverage these views include SOA administrators, product managers and configuration managers. Example views might include: Consumer/Service Dependency View, Policy Views, SLA Views, etc. These views help people to keep composite solutions from breaking due to incompatible versions, capacity problems, etc.

================

The power of SOA is that it is the first model that crosses these three areas. It has been my observation that the companies that balance these three broad views of SOA are the most successful.

Is SOA "predominantly an enterprise architectural style"? Well, it sure is if you're an enterprise architect! I understand that the evangelists in this group want to push the importance of the Service Portfolio Views. But, I'm going to pull a "Mark Baker" and become religious about the "Balanced Views of SOA" - that's my New Year's Resolution :-)

=== This is a repost from the Yahoo SOA Group

Top 100 SOA Predictions for 2008

Here are my top 100 predictions for the SOA community:
#1 - The incredible value of SaaS is realized and buyers want in
#2 - The buyers realize they need enterprise SOA to effectively pull off SaaS

#3 - #100 are irrelevant.

Updating the SOA Scorecard: SCA Services

For almost 5 years now, we've been advising clients on their SOA scorecard. In the early days of SOA adoption, customers often measure their success by 'releasing services'. This is a great metric for beginners. As the program progresses the shift moves to their utilization. Services are only valuable if they are actually used. From this perspective, we recommend looking at the consumer-to-service ratio as the primary test. The secondary test looks at message counts; that is, are the services actually being called.

Unfortunately, neither of these tests actually look at the value that software brings to the business. We've been encouraging our customers to spend more time looking at the business proposition that the service reflects. Business strategy is based on those activities and assets which are considered 'Sustainable Competitive Advantages' or SCA. These are the things that allows a company to be successful in their business year after year. Strategist have various means of identifying and describing the SCA's. Moore's 'core vs. context', and 'value chains' are often applied to help an organization understand where they need to be competitive.

Many organizations have moved beyond SOA pilots and now have scores of services running in production. However, many of these same organizations do not have the truly important services available. The fixation to increase the number of services often overrides the commonsense notion of providing business-valued services.

I've been encouraging customers to look at the three C's of business: Customers, Commerce and Channel. All three of these domains are typically excellent candidate for service enablement with high business value. Obviously, there are other domains that might be more important for your business which should be prioritized higher. The point is that you need to create a priority list of services based on the business that you're in. Service enabling non-valued added aspects of the business might look good on an old fashion SOA scorecard, but it no longer passes the smell test!

Amazon SimpleDB Launches

Amazon Web Services has launched their latest offering, "Amazon SimpleDB":

"Amazon SimpleDB provides a simple web services interface to create and store multiple data sets, query your data easily, and return the results."

SimpleDB sits on top of their hosted computing layer (EC2), proving an integrated cost model for those who are already EC2 customers. From a developer perspective, SimpleDB looks more like a big 'hashtable in the cloud' than a traditional RDBMS. The database is not relational and doesn't support SQL for data definition or data manipulation (DDL/DML). Instead, they have chosen to use a 'schemaless' system for data definition (name/value pairs) and for data manipulation (insert, update, delete) they have chosen to use simple REST style verbs (PUT, GET, DELETE, CREATE, QUERY).

The service is specifically designed for small payloads (not big BLOBS). For larger files, they recommend that you use AWS S3. They also recommend that you only run 'real time queries'. In fact, query execution time is limited to 5 seconds which prevent users from running very large requests. Although some might disagree with this decision, I'm a full supporter of this model. However, organizations will still need to perform two vital operations: 1. Export all data 2. Perform complex BI style queries. It is currently not clear how these items will be supported. The system doesn't seem to support the notion of 'change data capture' which would allow changed records to be sent to a separate analytics engine, nor am I finding a mechanism to easily load or unload a data store which would be a real issue if you time out after 5 seconds...

SimpleDB is in beta which implies that features have been frozen while bugs are ironed out. My primary concern is that they may have accidentally designed "TooSimpleDB". I love the idea of keeping it simple, but they may have overdone it.

Replace SOA Governance with Expertise?

Owen Pettiford takes a swipe at SOA Governance:

The reasons for this conclusion stems from the drug induced high I was on just after the operation when it occurred to me that I had not just survived the biggest operation of my life because someone "governed" it well (sure it was important that the right people were there and that they had the right tools) – I survived because I had EXPERTS working on me who had TRAINED for YEARS.

Well, I partially agree with Owen. Let's not forget that much of the doctors training was on the best practices (sanitary environment, cross-checks, standard procedures, etc.)

SOA Governance isn't a magic bullet. But if it is implemented correctly it will prevent (some) people from doing (some) stupid stuff (some) of the time. And I'm ok with that.

He goes on to say:

Enterprise SOA will be achieved through expertise, passion and shared vision.

You could replace "Enterprise SOA" with just about anything and you'd be correct. The problem is that large organizations are filled with people who are non-experts who don't have passion and lack shared vision. It's that simple. Good SOA Governance makes the assumption that statistically, the average person in your organization is, well, average!

See:
http://pettiford.blogspot.com/2007/04/governance-is-not-answer.html

SDLC and Work Patterns

Nick Malick stumbled upon a real common misconception. In a recent blog post he mentioned that a SOA SDLC must be more iterative:

First, a comparison: Waterfall looks like this:
Waterfall: Plan --> Envision --> Design --> Develop & Test --> Deploy
Agile: Plan --> Sprint --> Sprint --> (occasionally) Deploy --> Sprint --> Deploy

A SOA SDLC looks more like this:

Plan --> Sprint (Process and User Experience) --> Sprint (Process & Services) --> Deploy --> Sprint (P&UX) --> Sprint (P&S) --> Deploy

What Nick is describing is the use of Work Patterns within an SDLC. It is common for people to accidentally combine these two distinct concepts.

Here's the difference...
- SDLC focuses on the phases, activities and artifacts
- Work Patterns focus on the selection of phases, iterations and workflows

It's hard to describe but take a look at this and I think you'll see what I mean:
http://www.usdoj.gov/jmd/irm/lifecycle/table.htm

See section 13.2 for an example. I do agree that running a serial SOA SDLC is not a good thing. I was glad to see Nick mention User Experience. Usually, we'll talk about the Consumer SDLC and aligning it with the Service SDLC.

Good Stuff!

Ruby on Rails picks REST, will you?

Just out...
http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

ActionWebService out, ActiveResource in

It’ll probably come as no surprise that Rails has picked a side in the SOAP vs REST debate. Unless you absolutely have to use SOAP for integration purposes, we strongly discourage you from doing so. As a naturally extension of that, we’ve pulled ActionWebService from the default bundle. It’s only a gem install actionwebservice away, but it sends an important message none the less.

This is an interesting question: When do you have to use SOAP? or WSDL? The answer is that rarely do you "have" to use it. The two most common reasons for using it are
1. It's the corporate standard (someone tells you to)
2. You have some software that only speaks SOAP

I'm a fan of using the smallest amount of protocol to accomplish the job at hand. REST is about simplicity - simple to design, simple to consume. And simplicity introduces scalability of human consumers. That is, it doesn't require reading gobs of white papers on the subject to understand it.

The funny thing is I'm also a fan of protocol extensions. The big idea behind the WS-* stack was that it didn't require you to use all of the WS-* stuff at once; you were able to pick and choose the elements you needed. You could use the basic messaging stuff and throw in a bit of security. If you don't want security, don't use it. You need transactions, hell throw that in... What the REST approach seems to be telling the Web Services world is that even the light stack (WS-I Basic Profile) is too fat. And I agree.

Clearly, I'm not alone on this. Plenty of people have pointed figures at the WS-I and called them ugly names. However, I haven't picked up anything from the WS-I organization suggesting that they realize that their lightweight stack is too fat. Instead of working on an even slimmer profile (call it the WS-SuperLight Profile), they are adding new WS-Fat stuff to the mix. I can't make it any clearer than this: WS-* is dead unless they create a lighter weight protocol.

True RESTifarians will point out that REST isn't really about a 'lighter stack' but rather the genius of REST is in the tenets of the disertation. I mostly agree but I think that there are still variations of the tenets that need to be explored. For example, some might argue that if a new profile was created that Relax NG might be strongly considered as an element.

Regardless, it is clear to me that the WS-I is too fat and about to have a heart attack. But rather than going out and exercising, the leadership team seems devoted to going out and eating a couple pounds of cheese cake. WS-* will collapse if measures are not taken - and soon.

The Next Phase of SOA

I've spent the last couple days at the Gartner Application Development and Integration Conference in Las Vegas. As you might guess, the majority of the show was really about Service Oriented Architecture.

Like many SOA events, there were plenty of sessions on SOA governance, strategy, quality and implementation technologies. New this year was a strong focus on Web 2.0 as the consumers of the services.

Despite all of the good sessions, there was a void around "Information Modeling for SOA". The process of analyzing and designing an information model that mimics the business is a huge issue at every client that I work with. Many of our clients have moved past the initial planning and setup phases of SOA and are out designing and building services. Companies are realizing that having pockets of service teams (working in silos) leads to a collision of service semantics.

Nick Gall, Gartner Guru, commented that this year everyone seemed to be on the same page. The vendors, consultants, analysts and buyers were all in agreement about the steps you take to roll out SOA, the kind of infrastructure you need, etc. In essence, we've been doing it long enough now that there are well known success patterns that are rarely disputed. Nick was also quick to point out that we're not home yet. Like me, Nick feels that Information Modeling for SOA remains a deadly issue for many organizations. Whew! I was so glad to hear that I wasn't alone out there.

He drew the analogy to the database world. Today, most I.T. savvy people know the basics about how to design databases. However, it is a much smaller number of people who are experts in database design - the kind of people who can tell you the difference between 4th normal form and Boyce-Codd normal form. In SOA, we lack the equivalent set of rules for modeling services. In SOA, most people don't even know the equivalent of 1st normal form. Guys like Thomas Erl have thrown out the basics of service design, but it is hardly enough to avoid the pitfalls.

And the issue is much larger than just designing a single loosely coupled service. The real issue is designing a portfolio of services without creating redundancies or conflicts in the message model. Imagine taking the message models of all of the services across a domain (or set of domains) and reconciling their semantics. This view is takes the service out of the 'semantic silo' and begins to introduce an enterprise vocabulary. And like all data, relationships will exist. Here is where it gets interesting. Many people have focused on 'decoupling clients and services' (which is great), but have completely forgotten about decoupling the data model (or service model if you prefer). Pull out a large ER-model and look at all of the relationships between tables. When you resurface the data models as business or data services those relationships will still exist.

The collection of services and their message models is what we call the Enterprise Service Model (ESM). The science of creating the ESM is centered around "Information Modeling for SOA". More to come on this...

Service Oriented Analysis - Harmony

Alex Rosen of MomentumSI recently introduced our method for Service Oriented Analysis. Check this out for a great overview.

BEA Systems or BEA Consulting?

Today, BEA announced their 3rd quarter results:

BEA reported third quarter total revenues of $384.4 million, up 11% from last year's third quarter. BEA reported third quarter license fees of $134.8 million, down 1% from a year ago, and services revenue of $249.6 million, up 18% from a year ago.

249 million in service revenue represents approximately 65% of the overall revenue, well beyond the norm. As if BEA wasn't facing enough challenges, they'll now have to answer the very difficult question of valuation. Should BEA be valued as a product company, a services company or a hybrid.

According to Google Finance, their current Price-to-Earnings is 46.31. This is out of whack relative to competition (ORCL, TIBX, etc.) and is even farther away from the valuations of service companies like Accenture, who P/E is 18.6.

Assume for a moment that speculators weren't holding up the BEA stock awaiting an ORCL acquisition; what would happen? What if... Wall Street called BEA on their revenue split and began to value them as a service company? If you were to use consulting valuation multipliers, you might see BEAS price drop to $7 per share, immediately erasing several billion dollars of market cap.

BEA is in a tough position, they need to show year-over-year growth and strong earnings. They were able to accomplish this by creatively finding revenue. This strategy may pay off in the short term, but this quarter over quarter pattern is looking less like a stop-gap measure and more like a business model.

Looking back 10 quarters...


"If it walks like a duck and quacks like a duck..."


Disclaimer - Do not make investments based on this information.

Power to the People, SOA Style

Guerrilla SOA advocate, Jim Webber comments, "One by one your services will be stripped from the clutches of enterprise architecture and governance teams and returned to the (business) people."

Enterprise architecture is responsible for creating SOA principles, methods, policies and infrastructure. They do this to ENABLE project teams, not to OWN the services. Often EA will work with 'zone architects' to help identify conceptual services so that the 'just build it guys' don't recreate stuff that already exists. I'm not sure where Jim got the idea that EA owns the services... perhaps that is common in Europe?

What I don't like about Jim's comments is the "us against them" mentality that he is provoking. Is EA an evil organization plotting to destroy the business? The enterprise architects that I work with know that there is no way that they could "own" the thousands of services in a large Enterprise. However, it is common for EA to champion "enterprise services" like customer and product. I think that Marty Brodbeck of Pfizer clearly demonstrated the need for creating a certain set of Master Services when he described the relationship between SOA and MDM at the InfoWorld conference.

Someone asked me if I disliked 'Guerrilla SOA' and I told them, "I have no idea if I like it or dislike it because it has no shape or form. Right now it's just a funny name to a concept that implies applying agile principles to SOA." I'd suggest that the advocates put some additional thought around the concept.

Jim Webber didn't refer to his concept as 'Chaotic SOA'. This implies that there are rules. However, I have no idea what they are. My guess is that Guerrilla SOA will end up looking much more like Enterprise SOA than Chaotic SOA.

Obviously we can't just yell, "power to the people!", although it sounds cool and is a lot easier than thinking it through :-)

The Enterprise SOA Manifesto

Recently, the SOA camp has entered into a period of self-reflection and evaluation. Through this endeavor, the camps are dividing. There are those who feel that SOA aligns more closely with the concepts of enterprise architecture and there are those who feel that success can only be driven by more agile, quick hit wins. The optimal answer is likely somewhere in the middle... an approach that blends the best of EA with the best of Agile.

In the vein of the "Agile Manifesto", I'll post my position and invite my colleagues to offer their ideas.

First, it is worth defining Enterprise SOA. The definition that has evolved from working with our customers is,

Enterprise SOA is:

• An Enterprise IT Strategy that encompasses a set of business, process, organizational, governance and technical methods.


• It enables business agility through the use of loosely coupled services that are used as building blocks to develop composite applications that can be reused and recombined to address changing business priorities.
  

Complementing this definition is a set of supporting philosophies. Note that these philosophies are about Enterprise SOA, not just 'service oriented architecture', which has already been covered.

The Enterprise SOA Manifesto

1. Communities over Silos
   Enterprise Architecture focuses on creating portfolios of integrated software to fulfill a business mission. Although application silo's can often be created more quickly, the long term process of integrating silo's of logic, data and policy create spaghetti architecture, demoralize teams, stagnate innovation and increase long term maintenance costs. Communities (or application portfolio domains) should adhere to enterprise standards while each zone tailors the localized rules and regulations.



2. Balanced Planning over The Extremes
   Enterprise SOA attempts to balance 'planning' versus the extremes (too little/too much). The popularity of the Agile movement was largely a knee-jerk reaction to the frustrations with "waterfall planning". Enterprise SOA blends long term planning with tight iterations. Think, "planning in the large, agility in the small".



3. Governed Delivery over Ad-hoc Delivery
   The enterprise must prioritize the needs of the many over the needs of the few. Applications must be architected to fit into an ecosystem of applications. This will require adherence to guidelines and policies on technical standards and software processes, employed to protect the long term interests of the community.



4. Sharing and Reuse over Building from Scratch
   Portfolios of applications will have many common functional requirements. An implicit non-functional requirement in Enterprise SOA is to design for sharing and reuse where appropriate.



5. Business Priorities over the Enterprise SOA Manifesto
   I.T. systems are either a reflection of the business today or a projection of where the business is heading tomorrow. The I.T. approach must not become a religious battle fought at the expense of the business. On occasion, it will be in the best interest of the business to violate the principles of the Enterprise SOA Manifesto for the purpose of 'doing the right thing' for the business. Appropriate planning, governance and leadership should make this the exception, not the rule.