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.
   

JackBe Closes $9.5 Million in Growth Funding

JackBe, a leading provider of mashup software, has closed on a new round of funding. This is a Series C round and should provide them the resources to continue building out their platform and sales engine.

I had the opportunity to speak with JackBe CEO, Luis Derechin, earlier this week. First, I have to publicly congratulate him on running (and finishing) his first marathon! I'm sure there are plenty of parallels to be drawn with running his business...

A couple interesting topics were discussed in our meeting. The first was the inevitable maturation of the market from widgets to platforms. Like many RIA vendors, JackBe initially focused on AJAX widgets and presentation layer accessories. Their business has grown into server-side mashup engines capable of integrating data from a variety of sources (databases, legacy systems, Web Services, etc.) and transforming the transports, payloads and data into easy-to-consume formats for Web 2.0 developers.

I believe that the mashup layer will quickly become an essential element in User Experience Reference Architectures (UE-RA's). The focus of older portal technologies is 'on-the glass integration'. Here, disparate data sources are pulled together as a set of portlets (or windows). Conversely, the Mashup Layer focuses on what I've been calling 'before-the-glass integration'. This enables new functionality to be inserted between consumers and providers (think clients and services), aimed at providing mediation and transformation services 'just in time' based on the context of the consumption.

Because this software is positioned squarely as a presentation layer-to-service go-between, it has the unique advantage of also enabling wide scale governance through policy visibility and control mechanisms. Think of it this way. Today we have 'mash-ups' tomorrow we'll have 'crash-ups'. Service interfaces will change, as will formats and protocols. This places new challenges on software configuration management and the overall governability of the Web 2.0 solutions.

We saw a similar trend in the SOA world where vendors who provided intermediaries had to make a decision. Are you the source of governance policies or the target? This is a fundamental question that each vendor will have to resolve. Said another way, will your tagline be "Mashup Governance" or "Mashup Enablement". That said, a key attribute of Mashup Enablement will be providing Policy Enforcement Points (PEP's), fed by governance vendors.

Over the last 5 years, many of us SOA-guys have put extensive thought into every aspect of the 'service provider' aspect, while neglecting the 'service consumer'. However, an acknowledgement that more advanced UE-RA's are needed will hopefully draw out other Enterprise Architects to surface a more in-depth discussion on this very important topic.

Quit the Clowning

Joe McKendrick is confused. In his latest blog post, "Enterprise SOA Concept Falls out of Favor", he implies that 'enterprise SOA is failing' which couldn't be farther from the truth. I believe that his bad information comes from people who don't know SOA, don't do SOA and in some cases, caused the mess that SOA cleans up.

In my position, I have visibility into HUNDREDS of SOA programs. Many are active clients - many are past - many are just companies that I've had the privilege to speak with. And through my partners, (the leading SOA infrastructure companies), I have excellent visibility into their historical sales and future demand pipeline. Between these vehicles, I am able to see commitments related to SOA strategy, training, governance, architecture, infrastructure, organizational design, change management, packaged application enablement, service integration and composite application development. That said, I feel like I'm in an excellent position to comment on what is really going on with regard to SOA.

First, SOA is nowhere near the mythical Gartner beast called, "The Trough of Disillusionment". And I think it's funny that people keep trying to force us in that phase so that we can then say we've moved past it. Nope. We're not even close.

Second, the idiots that are running around yelling "guerrilla SOA" have to be put in their place. Many of these individuals are the ones responsible for silo-oriented thinking in the first place. They proposed small (agile) projects where we captured just enough requirements to begin coding and releasing. Guess what? This style of development doesn't jive with the concept of shared services. It is the cause of the problem, not the solution.

We love to compare EA to city planning (plotting out neighborhoods, identifying common infrastructure, etc.) Yes - this requires using your brain and creating a plan. Enterprise SOA involves long term planning coupled with short term results.

Don't get me wrong - I'm a fan of 'controlled agile'. The rules of agile by themselves are so incredibly destructive to large organizations that they have done immense harm. Shouting 'agile manifesto' at people who have to build real 'application communities' is a non-starter.

I am proud of the companies that I work with who take the time to think about what SOA means to them. They plan their community. They consider the common infrastructure. They create policies and rules for their citizens. They identify practices to build the structures (reference architectures). And once they've figured out how to build a community they go do it. They don't do it for the entire enterprise all at once - that isn't what 'enterprise SOA' means. Instead, they partition their enterprise into a set of communities and attack them, often in parallel.

Let's be clear. Enterprise SOA is, by far, in the strongest position it has EVER been in. The jokers who feed columnists bad information need to go away. But this won't happen on its own - it requires the columnist to call them the clowns that they are.

Consolidation in the Software Industry

In June of 2003 I noted that, according to Yahoo Financials, Microsoft was larger than the next 40 largest software/service companies:

Quest Software, Inc. + Tibco Software, Inc. + Documentum, Inc. + Take-Two Interactive + Activision, Inc.+ Hyperion Solutions Corp. + Sybase, Inc. + Macromedia, Inc. + RealNetworks, Inc. + Business Objects + Cognizant Technology Sol. + Red Hat, Inc. + Satyam Computer + J.D. Edwards & Company + Autodesk, Inc. + CSK Corporation + Network Associates, Inc. + Konami Corporation + Compuware Corporation + Trend Micro Incorporated + Cognos Incorporated + Mercury Interactive Corp. + VeriSign, Inc. + Citrix Systems, Inc. + Cadence Design Systems + BMC Software, Inc. + Amdocs Limited + BEA Systems, Inc.+ Synopsys, Inc. + Siebel Systems, Inc. + Check Point Software Tech + PeopleSoft, Inc. + Infosys Technologies Ltd.+ Symantec Corporation + Adobe Systems Incorporate + Intuit Inc. + Electronic Arts Inc. + VERITAS Software Corp. + Computer Associates + SAP AG + Oracle Corporation

As I scanned this list, it occurred to me how many of them have been acquired...

1. Documentum --> EMC
   
2. Veritas --> Symantec
   
3. Hyperion Solutions --> Oracle
   
4. Macromedia --> Adobe
   
5. Business Objects --> SAP
   
6. J.D. Edwards --> PeopleSoft / Oracle
   
7. Network Associates --> McAffee
   
8. Mercury Interactive --> HP
   
9. BEA Systems --> ??TBD - Oracle??
   
10. Siebel --> Oracle
    
11. PeopleSoft --> Oracle
    

It is interesting to look at the list of companies that didn't get acquired. Let's remove the non-enterprise I.T. companies (entertainment software, semiconductor, consulting). The odd balls include: Sybase, Tibco, Cognos, Adobe, Citrix, BMC, Red Hat and Computer Associates. In my opinion, these companies need to find a home - and soon.

Companies that have had significant growth since my last post include:
VMware, Inc. and salesforce.com, however you should note that their PE's are 269xTTM and 1,245xTTM - and in my humble opinion - this is just a tad bit inflated! At some point these companies are going to have to increase their top line numbers. Regardless, we've entered into a period of massive consolidation where few new companies can truly shake the market.

SAP TechEd - We Have SOA (for real this time)

I've been attending the SAP TechEd in Las Vegas conference for the last few days. Overall, I'm impressed with the reality of the story that SAP has put together. In the past, SAP had a SOA-by-PowerPoint story. Today - they have real products and guidance.

At the core of the SAP SOA story is the Enterprise Service Repository (ESR). It is actually a combination of both registry and repository. The registry is a UDDI 3.0 implementation and has been tested to integrate with other registries such as Systinet. But the bulk of the work is in their repository. Unlike other commercial repositories, the first thing to notice is that SAP's is pre-populated (full, not empty). It contains gobs of information on global data types, schemas, wsdl's and similar artifacts relating to the SAP modules.

Both the registry and the repository are designed to embrace service metadata that is housed by SAP as well as service information that might be in other platforms (IBM, Microsoft, etc.) And although the registry will do metadata interchange with other registries, we're not so lucky with the repository. Apparently the current version is designed to be a single instance across the entire enterprise. Of course, this isn't realistic in most organizations due to mergers & acquisitions, etc.

SAP has also customized the TOGAF enterprise architecture to meet the needs of large customers. I was hoping to learn more on this but the speaker failed to show up (bummer). However, it was clear that SAP is relying on IDS Sheer to supply EA modeling tools.

I felt like SAP really got it. Unfortunately, I felt like most of the people at the conference didn't. The gap between vendor and customer has grown significantly. Many of the SAP customers have avoided technology topics, favoring black box implementations of large monolithic applications. SAP is introducing a fundamental change that will take time to sink in. They are doing a great job of evangelizing and providing community guidance but this is a huge leap for many of the 'ABAP' programmers of today.

A Watched Pot Never Boils - SOA Style

Literally - I was trying to boil some water today. While staring at it, I began thinking, "My God this is taking forever!". A Watched Pot Never Boils. Sadly, too many of my life experiences end up relating to SOA...

Some journalists and bloggers have been critical to the success of SOA. Personally, I view it as a "watched pot". Impatiently staring at an SOA effort and constantly asking, "How many services do we have?" or "What's the ROI?" - doesn't really help.

SOA is a long term change to I.T. - it will take time. I've seen HUGE changes take place in some of the world's largest corporations. I've also seen companies with poor I.T. leadership whine about how they failed. Hell, I could have told them that they would have failed at about anything they tried.

I guess what I'm trying to say is that I don't think that the journalists / bloggers should ask EVERYDAY, "are we there yet?" It's annoying and not helpful. And the LOSERS who threw in the towel - well, they're losers.