New Blog on Cloud Computing

SOE isn't dead but my primary go-forward blog will be:
http://cloudv.blogspot.com

Nomination for Federal CTO

From the Barack Obama campaign site:

"Obama will appoint the nation's first Chief Technology Officer (CTO) to ensure that our government and all its agencies have the right infrastructure, policies and services for the 21st century. The CTO will ensure the safety of our networks and will lead an interagency effort, working with chief technology and chief information officers of each of the federal agencies, to ensure that they use best-in-class technologies and share best practices."

I nominate Tim O'Reilly as the first Federal CTO. Do I hear a second??

Is Amazon Competing with RightScale?

It looks like RightScale is going to be a 'multi-cloud management suite', see;
http://www.allthingsdistributed.com/2008/10/using_the_cloud_to_build_highl.html#comment-2061

16 Corrections on Cloud Computing

In March of 2008, RedMonk analyst, James Governor, submitted his list of "15 Ways to Tell if it's not Cloud Computing".

The consultants at MomentumSI have found 16 corrections:

Real World SOA

It was my pleasure to be a guest on the Real World SOA Podcast with David Linthicum. Take a peek:

http://weblog.infoworld.com/realworldsoa/archives/2008/10/my_conversation.html

Topics:
- How do we help organizations with SOA?
- What is the purpose of a SOA methodology?
- What is the next big thing???

Talking to the Business about SOA

Recently, there's been more chatter about how (or if) you should talk to the business about SOA. Yesterday, I sat in on the SOA Consortium conference call where this was the main theme. Interestingly, the moderator posed the questions and a couple participants were quick to respond... "we don't talk to the business about SOA..." The moderator took it in stride and started down the path of business and I.T. alignment - and once again the participants pushed back. Not to be dissuaded the moderator went down the BPM path. Once again, the participants pushed back. The group commented that, "talking SOA is too abstract for the business" and there was a "need to talk about business specific functionality vs just high level Agility and Change".

After attending this call, I stumbled on to Joe 2.0's blog post on the exact same topic! Even funnier was that he was quoting Jean-Jacques Dubray (JJ), who I had a 3 hour phone call with on the subject just days earlier. JJ had commented, "My experience is that the key people that you have to focus all your energy on are the developers, architects, business analysts, QAs and operations."
Joe 2.0 goes on:

Dubray says SOA is a “pure IT problem.” But in this era of the online collaborative organization, when we rely on technology for every aspect of our business, are there really any “pure IT” problems?

I don't want to split hairs... but IMHO, the answer is, "yes, some problems are just I.T. problems". Sure, I.T. problems, like HR or garbage collection, may bubble their way up to become a business problem, but at the end of the day I.T. has to figure out how to do their job and go do it. When the janitor picks up the trash in my office they do it in the most efficient way they know how. They don't ask 'the business' if they should do it efficiently - they just do it. When did I.T. become such wussies?

I'm a big believer in talking to business about whatever they want to talk about... Inventory Visibility? Love it. Customer Loyalty? Love it. New Product Introduction? Love it. That said, I believe it's I.T.'s responsibility to bring technology solutions forward. Most business people understand things like forms, window, graphs, reports, etc. They understand visual deliverables (not invisible deliverables like WSDL's). I think that is why we're seeing the most successful SOA shared service centers adopting capabilities around Rich Composite Applications, Mashups and other edge-of-the-enterprise development capabilities. They engage with the business about business problems and then use mashups and other techniques to quickly demo/prototype/build solutions that their users can relate to.

If you're looking for inspiration on this process, I'm happy to recommend a book on the subject, Mashup Corporations.
The authors do a great job of walking the readers through a fictional company. As business problems are encountered, they introduce Web 2.0 and mashup solutions. Prototypes are put together and the concepts are tested out. SOA is discussed as the 'efficient way' to make it happen. Again, they didn't talk to the business about SOA (or even services)!

PaaS Enables New ROI

If you haven't already checked out Amy Shuen's book, "Web 2.0: A Strategy Guide", you should grab a copy; it's worth the read. Amy discusses the trends around Web 2.0 in the clearest, most concise manner I could have hoped for. Enough bragging about her book - one of her diagrams inspired me to think about the effects that PaaS has on the Enterprise I.T. development model.

Amy pointed out that a version of the Long Tail lives in the I.T. application development world. Certain business problems (ie, order management) have a very real and significant value proposition; these systems are often purchased from ISV's. The next set of applications often have slightly less of an ROI and are often built by the I.T. custom development group. In many cases these are departmental applications or add-on's to the procured systems. Recently, new SaaS solutions are finding their way into the enterprise because they fulfill point-requirements and have a low-cost of entry.


In the past, this left lots of business problems in the hands of shadow I.T., or power-users. But all too often new systems concepts were taken to the I.T. review board and turned down because they didn't project an adequate ROI. The return on some of these systems may have been rewarding, but the initial investment (hardware, infrastructure licenses, long development cycles, etc.) drove down the overall ROI to the point where the idea was rejected. These systems are prime candidates for PaaS, where the initial investment is significantly decreased by the pre-hosted, pay-by-the-drink model. Once again, hosted platforms will likely be the key enabler of long tail opportunities.

The long tail model of reviewing new system requests is an interesting method for I.T. governance and planning committees to consider. It is my belief that if enterprise organizations fail to meet the needs of the long tail, they will be met by other 3rd party providers who will be all to willing to help!

Services, Mashups & Cloud: Puma

Imagine for a moment that Olympics took place in China – and all the world came out to watch. You’re with a shoe company called Puma, who for many years hid in the shadow of branding giant Nike. But this Olympics you made some interesting bets, including a big bet on a Jamaican sprinter named Usain Bolt. This distinguished athlete proceeds to win the gold and to destroy the world record – and to your delight holds up a pair of your shoes. What a dream.

For a brief period you own the consumer. Search engines are bombarded with “Usain Bolt” and even “Puma runner”. Your online store is blasted with orders but now every outlet that carries ‘hot tickets’ wants to resell the Usain Bolt Limited Edition shoes. Orders are coming in from channels you’ve never even heard of. New channels, new orders, new customers are abound and new demands are being placed on your I.T. environment.

The world of API’s (or services), mashups and cloud computing are all upon us. As many businesses continue cut costs and hunker down for a ‘wanna-be’ recession, others are innovating and driving new sustainable revenue sources.

Services, Mashups and Cloud drive business opportunities for those who seek a competitive advantage.

Services, Mashups & Cloud: Photosynth

Imagine for a moment that a Microsoft research group finished a beta version of a project that they had dubbed ‘Photosynth’. Their pet project was to allow users to create panoramic virtual environments by using regular 2-D digital cameras. Users would merely take lots of adjacent pictures where the edges of one photo would overlap with the next. The photos would then be submitted online to a set of computers that would use artificial intelligence to transform the individual digital pictures into a panoramic viewing environment that could be witnessed by anyone who had the Internet and a browser.

For this to be interesting a few things would be needed. First, we would need lots of people who could contribute pictures (user generated content). Second, we’d need a whole bunch of computers to act as one to crunch on digital image matching algorithms. Third, we’d need the ability to host the image online and allow the proud publishers to pass around copies of their new site's URL to all of their friends, encouraging them to become publishers as well. Imagine now, that the this happened and that the traffic to the site increased by 140,000% in just 7 days. Imagine that.

The world of API’s (or services), mashups and cloud computing are all upon us. As many businesses continue cut costs and hunker down for a ‘wanna-be’ recession, others are innovating and driving new sustainable revenue sources.

Services, Mashups and Cloud drive business opportunities for those who seek a competitive advantage.

Services, Mashups & Cloud: Shelfari

Imagine for a moment that an online ‘virtual book store’, called Shelfari, created a widget that displayed pictures and descriptions of the widget owners favorite books. These widgets could then be embedded inside of blogs and social networks so that people could see what their friends or influencers were reading. We’d have to assume that the widget was viral in nature, allowing consumers to copy the widget and republish it with their own content at their own site. And like all things viral, the network of users grew at an exponential rate. The widget became so successful that Amazon.com decided it was time to acquire the company. The press related to the activity drove additional traffic to the Shelfari site to the point where response times were so long that new users couldn’t even sign up.

What if – what if widgets drove traffic and viral widgets drove huge traffic? What if personalization drove conversion rates and Web API’s enabled financial transactions? What if we could mashup content and community to drive commerce? What if the hardware automatically scaled to meet the needs of the user community?

The world of API’s (or services), mashups and cloud computing are all upon us. As many businesses continue cut costs and hunker down for a ‘wanna-be’ recession, others are innovating and driving new sustainable revenue sources.

Services, Mashups and Cloud drive business opportunities for those who seek a competitive advantage.

Joe McKendrick 2.0

Joe McKendrick is one of my favorite bloggers over at ZDNet. However, I've found some of his stuff to be a bit hum drum. That is, until I found his 'secret' posting site...

Joe 2.0 (like Jeff 2.0), is spending much more time thinking, writing and talking about all of the reasons that you did SOA in the first place. Want to check out some good reading?

Mashups: So Easy a Caveman Can Write Them?

and

Managing Data in the Clouds

Fundamentally, SOA has progressed from debating about ESB's, governance styles, REST vs. SOAP, etc. to a discussion on how to use the services to create new business functionality through mashups, while delivering on low cost platforms (cloud and PaaS). Joe 2.0 gets it.

Are you 2.0?

Amazon Sends Death Blow to I.T. Data Center

The time of death for the corporate data center was pronounced at 11:03EST, August 21st of 2008. Forensic pathologists continue to investigate the death, however, it is known that the patient had stability issues, persistent hemorrhaging and had been considered terminal.

Thousands of companies have mortally wounded data centers. Unfortunately, CIO's lacked a viable replacement for this archaic agility anchor. In essence, they've been forced to keep them on life-support. Billions of dollars have been pumped into various unsuccessful attempts to heal the patient. Billions more have been spent on 'Data Center Hospice'. Jeff Schneider, MomentumSI CEO commented, "When it becomes it was clear that the patient will die, corporations shift their thinking to 'reducing the pain'. This largely involves moving labor intensive data center tasks to low-cost offshore facilities."

Although some debate remains if the data center is actually dead. Schneider stated , "Yes, the data center has a heart beat, however the beat coincides with the I.T. family beating on the heart with their fists, insisting that the patient isn't dead."

Congratulations to Amazon on delivering the last critical element of their Elastic Cloud Computing offering.

The 7 Dirty Words of SOA

I recently had a conversation with one of my good friends at IBM. He had mentioned that IBM is doing a better job of differentiating between "Business SOA" and "I.T. SOA". Interesting... what did he mean? After drilling him with questions it came down to this:

- I.T SOA is about running a more efficient Information Technology group

- Business SOA is about creating new information products and capabilities

This resonated with me. It sounded very similar to the conversations I've had with people at SAP. They have positioned SOA as a technology enabler to their large suite of business applications. They sell business solutions. And as one SAP insider put, "... and of course those solutions are Service Oriented... it's 2008!"

These conversations were music to my ears. IBM and SAP are both back to attacking business problems and are making the assumption that SOA is in place and acts as the enabler.

In Business SOA we need to think about a new set of "Business SOA Patterns":

- How do we deliver new business products through new channels?

- How do we deliver more/better information to our distributors, retailers and consumers?

- How will consolidated/shared information lead to a tighter supply chain?

It's been too many years of people talking about ESB's and other I.T. focused trivia. With that said, the 7 Dirty Words of SOA are:

1. Loose Coupling


2. Abstraction


3. Reuse


4. Autonomous


5. Discoverability


6. Composability


7. Interoperability

Yes, it's time to move past "I.T. SOA"...

New CEO at StrikeIron

I just noticed that Richard Holcomb is new CEO at StrikeIron, see:
http://www.strikeiron.com/company/management.aspx

StrikeIron has been pioneers in the 'Data as a Service' space for some time. Congratulations!

RFP's for Service Oriented Architecture

At MomentumSI, we keep a close eye on the various RFP's that are issued relating to SOA. Yesterday, one caught my attention, and I'd love to hear from the blogging community on what they think.

The issuer is the Rhode Island Administration of State Courts, RFP/LOI #: B2008011. This is an active/open RFP titled, "Service Oriented Architecture Implementation". Naturally, an initiative that MomentumSI would be interested in...

I encourage others to take a look at the RFP - I don't mean to single this particular agency out, it's just a concrete example that I believe will facilitate a conversation.

Bloggers, what I want to know is do you think this is a good SOA RFP?
http://www.purchasing.ri.gov/RIVIP/ExternalBids/Judicial/JudicialBids/B2008011.PDF

Speak up - I want to hear your thoughts!

(For the record, MomentumSI will not be bidding on this RFP)

SOA Governance Priorities

I've been sending out emails and making some phone calls asking a simple question. How are companies prioritizing the various aspects of SOA Governance, using the following categories:

A. Plan Time Governance - Ensuring that business initiatives aligned with key I.T. services, avoiding silos while gaining cross organizational funding, etc.

B. Design Time Governance - Utilizing registries, repositories, validation frameworks, etc. to promote best practices in schema and contract design enabling reuse, search, verify, etc.

C. Pre-Release Governance - Validating solutions meet pre-production needs (highly available, secure, fast response times, new version doesn't break existing consumers, etc.)

D. Run Time Governance - Ensuring that the services in production are monitored, adhere to SLA's, leverage run time policies, etc.

E. Infrastructure Governance - Verify that the infrastructure used (ESB's, Registries, Mediation Devices, etc.) adhere to the corporate standards.

I've got quite a bit of feedback (thank you). For the most part, people feel that B, D and E are getting the attention, while A and C are not.

Here's where I'm seeing people spend time/money:
(B, D, C, E, A)

Here's my personal opinion on where they SHOULD spend time/money:
(A, C, B/D, E)

Here's my take:
- SOA Governance = A
- B,C & D aren't actually SOA Governance, they fall under the umbrella of "Service Lifecycle Management"
- E is a form of EA Governance (applied to the SOA domain)

Most companies have completely failed in "plan time governance". If you're going to do "transformational SOA", this is a recipe for disaster.

Companies that choose not to tackle Plan Time Governance are doing something other than SOA. I like to call it SOB. More on this later...

Generational Platforms

Programming COBOL on the mainframe was the preferred platform of the generation before me. Don't get me wrong, I did my fair share. I did it, but I remember thinking that it was "my fathers platform".

I was a PC guy. When it was time to develop some new piece of software, the PC and personal OS was my starting point. I programmed in 14 different languages mostly client/server or monolithic clients running on Unix, Windows, OS/2, etc. It was obvious for me to see the benefits of this platform yet it surprised me that the last-gen often didn't get it.

In the late 1990's, I began working with people who were slightly younger than I. These people assumed that any new software built would be browser based. The Web was their platform. I remember thinking that the big thing was really Java, virtual machines, distributed computing, security sand-boxes, etc. The Web was limited in capability. Initially, I fought it - but then I got it. I laughed a bit about how I was getting old.

I'm now seeing a new paradigm emerge, once again, initiated by a younger generation. This group believes that software starts with social networks like Facebook and MySpace. It's less about the function of the software and more about the communities, relations and communications that they enable. Again, the last gen is challenged to understand the importance of this jump and many old-timers will not make the transition.

Evidence is also appearing to suggest that a second shift is occurring in parallel. That is, pervasive computing seems to have finally crossed the chasm. The iPhone has blazed a trail for a new generation applications available whenever and wherever you happen to be located. GPS enabled features brings a whole new dimension to the platform enabling scores of location based offerings.

This blog is about SOA - more specifically it is about services that enable productivity. It's often easy to get stuck in the old traps of debating stuff that doesn't really matter (REST vs. SOAP, do ESB's suck?, etc.) The exciting stuff that is going on in computing is related to the next generation platforms. The new generation doesn't care about the SOA debates - their debate is on geo-location services, cross-SaaS provisioning, etc. In essence, it isn't about SOA - it's about the next generation of services that enable pervasive computing on a social network. All of this other chatter is just last generation fools talking about stuff that only obsolete people care about.

Multiple ESB Example

David Linthicum accurately assesses my feelings:

http://weblog.infoworld.com/realworldsoa/archives/2008/07/esbs_on_trial.html

"I think Jeff may be a bit grumpy from even having to respond to this. However, once again, as I mentioned in my previous post, I'm looking for case studies and details that prove why I'm wrong, and thus why this is "silly advice." Thus far, it's been out there for 24 hours, and I've gotten zero responses. "

Now, I'm even grumpier for having to respond twice.

In Dave's own blog, within hours, of his post a gentleman responded,

FedEx Delivery is driven largely from a TIBCO-based platform. Kinkos is similarly built upon webMethods. Then they merge. It is simply not rational to think that we cannot provide FedEx with a solution to service orchestration across these 2 systems. That's the business need and what we have to solve for.

So FedEx has Tibco and WebMethods. This is interesting because my friends at SAP have told me that FedEx is a huge customer, hence, they'll probably be using the NetWeaver ESB functions as well. And when I last visited FedEx, they had purchased the BEA AquaLogic stack. My guess is that an Oracle account representative either has or will be talking to them about the virtues of Fusion Middleware and their migration plan. My guess is that they probably also have some DataPower boxes sitting around - and a few of the developers have probably downloaded Mule and are testing it out as well.

I know of no company who isn't facing the exact same issue. I'm surprised that Dave didn't run into this when he was at Mercator or Saga/Software AG. Not picking on Dave here, but it's funny, people always talk about being 'business driven, not I.T. driven', but then they make recommendations to rip out huge pieces of infrastructure to make "I.T Cleaner" because in the long run it will help business. Again, in my opinion, this is silly advice.

Linthicum on ESB's

Several people have sent me the latest Linthicum article on the back channel. People are asking if I agree...

http://weblog.infoworld.com/realworldsoa/archives/2008/07/are_esbs_hurtin.html

Dave comments:

First, if there is indeed "enterprise architecture" and an "enterprise architect" then the different divisions should not be using different ESBs, or even an ESB for that matter.

Companies are buying ESB's, will continue to buy ESB's, will buy products that are packaged with ESB's and will acquire/merge with other companies that have ESB's. They aren't going away - so yes, large companies will have to figure out how to deal with having more than one...


Dave moves on to his second point:

Second, considering that my first point is correct (which it is), why the heck are you attempting to integrate these integration engines when they should perhaps be displaced altogether.

In an overconfident, if not pompous manner, Dave declares himself correct. He then wants to know why a single dictator doesn't come in and end-of-life various products across business units, geographies and missions. Well, it might be a good idea for I.T. but may not be in the best interest of the business.

Personally - I see this as just plain silly advice...but perhaps, I misunderstood his point.

Silo Analysis: Key to SOA Success

At virtually every conference I attend, I hear someone declare that we need to "destroy the silos", and that SOA is the enabler. Loosely, I think of a silo as a system or information repository that solves a problem for some portion of the enterprise, while leaving other areas responsible for solving the same or similar problems on their own. Silos causes duplication of systems, business rules and data. They require multiple levels of integration and cleansing, resulting in increased maintenance and operational expenses. In general, silos are bad.

After working with a handful of organizations, it occurred to me that these companies had not performed "Silo Analysis". Almost every large organization has a number of silos that exist for a variety of reasons including:
- I.T. funding occurred by business area and each area bought/built their own (silo) systems
- Mergers or acquisitions caused duplicate (silo) systems
- Poor visibility or planning across the enterprise led to unintentional silos

---

The rumors that SOA can help are true. But before rushing down the path, organizations need to ask some important questions:
- What are our silos?
- Is there a good reason for the silos?
- Which silos do we want to end-of-life?
- Which silos can we practically kill (politics, investment, etc. )
- Will SOA lead to "silo services"?

Silo Identification
The first step to this process is to identify what silos you currently have. As I mentioned earlier, silos often mimic organizational reporting and funding structures. Here are some easy ones to look for:
- Corporate Sectors / Divisions / Business Units / Departments
- Sales Centers (Asia, Europe, Americas, etc.)
- Facilities (warehouses, manufacturing locations, distribution centers, etc.)
- Delivery Channel (Web, kiosk, mobile, etc.)

It is common for these structures to be embedded within each other as well. For instance, Acme Corporation might have duplicate CRM systems for each SBU, but also have additional CRM systems in the Asia locations of each SBU. In essence, the silo analysis has to look at combinations of the structures.

Silo Justification
Not all silos are bad. There are often good reasons why silos exist. Unique business requirements may require unique I.T. solutions. It is important to understand WHY the silo system exists but be careful not to let the 'unique business requirements' become a universal excuse for duplicate systems.

Silo Targeting
Once you've found silo systems which could be rationalized to a single service, you have to decide if their is political will power to "de-silo" the area. In many cases, if not most, it is very difficult to retire systems. The upfront cost of retiring a system is often a burden that an organization will attempt to defer for as long as possible, typically stating there are "higher priorities". The bottom line is that there will always be higher business priorities but I.T. must make the case for retiring the old.

Often the goal isn't to retire the systems but merely to create a single point of entry. In such cases, I.T. can create front end interfaces that access multiple legacy systems which cross silos. Here, we aren't retiring systems, rather we're 'bridging the silos' by standardizing the access point allowing consumers to get a single view.

Preventing Silo Services
Service Orientation offers a great mechanism to decrease the number of silos and mitigate the damage of the silos which can not be eliminated. From a rationalization perspective, SOA offers the ability to create a single "Master Service" that acts as the single source of truth for logic AND data. However, many organizations are not realizing this vision. As many have noted, services continue to be built in an ad hoc fashion resulting in JBOWS (Just a Bunch of Web Services). In almost every case JBOWS are merely silo services that were created because no one funding authority had the charter to perform silo analysis and justify a non-silo solution.

Although the 'governance' and 'cross-silo funding' problems are barriers, I believe a more tactical barrier remains. I.T. leaders are failing to teach their organizations about the silos. What are the silos? Why do they exist? Which ones are we chartered to knock down? Which will be tactically bridge? And when we do knock them down, how will we advertise that a service isn't a silo service, but rather a Master Service that crosses the divide? And perhaps most important, how do we prevent 'silo creep' in the future. Today, most software professionals have no concept of 'attaching' their unique business logic to existing services.

The Bottom Line
SOA offers a great solution to the silo problem but it will take significant political power to pull it off. Even if you are able to remove some of the silos, you'll need a plan to prevent unwanted new ones. Silo Analysis must be ingrained in the mind of every business analyst, architect, developer and governance professional. Failure to teach our next generation will lead to more silos - they'll just be written in Ruby instead of Java...

Mindreef acquired by Progress Software

Wow - how did I miss this one??

Mindreef was acquired by Progress Software!

Quietly, Progress added another set of tools to their growing SOA portfolio. Through this acquisition, Progress picks up new SOA testing at quality management solutions. Congratulations to Frank Grossman the rest of the Mindreef team.

And again, I've updated the SOA Acquisition List:
http://www.momentumsi.com/SOA_Acquisitions.html

Iona acquired by Progress

Progress Software announced the acquisition of Iona.

This move continues to round out their SOA offerings by adding registry/repository, data services, message brokering and CORBA middleware. However, as others have pointed out, this leaves Progress with significant overlap in the ESB area. I'm confident that we'll be hearing from the Progress leadership on how they intend to resolve the redundancies that exist between Artix, FUSE, SOAPStation and SonicESB.

Naturally, here is the updated SOA Acquisition List.

Gartner: Force.com Case Study

Highlights from the Force.com Case Study presenation inlcude:

MS client/server developers will quit when you move to SaaS. Hire web developers to replace them. Those people then implement innovative ideas rapidly on the SaaS platform.

Don't underestimate the need for change management training in this or any software rollout.

Developers productive within two weeks.

Easy to train up people in India to be productive on the platform.

Myth is that data on SaaS platforms is not available. Customer downloads all data from all SaaS providers onto their SAn nightly.

Very excited about their release of SAML. Seems to be standard most vendors are coalescing around.

Gartner: SOA Design Patterns

As you know design patterns describe recurring solutions to common problems in software design. And recognizing and implementing these patterns is an essential part of successful Service Oriented Design. Below are 5 SOA design patterns that Gartner analysts have observed:

1. Multichannel Applications
2. Composite Applications
3. Business Process Orchestration
4. Service Oriented Enterprise
5. Federated SOA

Multichannel Application
SOA is a perfect fit for multichannel applications. This pattern separates the back-end business logic from the front-end logic and delivers full application functionality to a maximum number of users from various channels in a minimal amount of time while reusing the same exposed services.

Strategic Planning Assumption: By 2008, more than 66% of new midsize and large interactive applications will be designed to support multichannel access, up from less than 33% in 2007.

Composite Applications
Services used in composite applications may be new service implementations, fragments of old applications that were adapted and wrapped, or combinations of the above. Two types of integration technology are essential for effective operation of a composite SOA environment: 1) integration technology behind the service interfaces, helping users wrap and adopt various pre-SOA applications; and 2) integration technology helping users assemble and monitor transactions from services.

Strategic Planning Assumption: Through 2012, the majority of SOA-style applications will be interactive composite applications.

Business Process Orchestration
Business process management (BPM) suites are the tools devoted to implementing such SOA-based multistep processing flows. The BPEL standard is often used to document the designed metadata flow model. The metadata repository ("meta-database") is used to manage the proceedings of the business process model at runtime. Some steps of the process are implemented by calling
SOA services. Other steps require human intervention.

Strategic Planning Assumption: By 2009, more than 75% of SOA applications will implement some sequencing control outside of code of the service implementations, via external BPM technology.

Service Oriented Enterprise
The SOA-based enterprise model is a step beyond composite applications. Here, all applications are perceived as components of one integrated whole. No new application is created in isolation. Each application is built from reusable components that are available for use not only in their initially intended context, but also by other clients in other contexts. Essentially, the integrated composite enterprise consists not of applications, but rather business components — each an asset of the entire enterprise.

Strategic Planning Assumption: By 2010, more than 85% of enterprises will have combined their application integration and SOA management tools and organizations.

Federated SOA
The fundamental idea behind federated SOA is to logically split the enterprise into semi-independent SOA domains (for example, reflecting the enterprise organization in terms of subsidiaries, Business Units or departments), each with its own specific SOA infrastructure, governance processes and SOA Center of Excellence. Domains are then federated (that is, integrated — usually, but not necessarily, after the fact — to enable inter-domain sharing of services) through appropriate interoperability infrastructure, governance processes and organizational settings. "SOA federation" is the process of enabling a federated SOA by establishing the
proper technical, governance and organizational capabilities.

Strategic Planning Assumption: Few large organizations are able to establish a singular architectural blueprint for their entire IT. The best practice is to endorse domain independence and allow them to differ in technology and architecture in exchange for agreement to synchronize interoperability protocols and transports. Mergers and acquisitions are clearly candidates for Federated SOA.


Posted by Tony Cook

Gartner Update: The People Side

Massive changes coming:

IT organizations are becoming change saturated. Both home and work. In next 20 years will experience the world going through peak oil production of all time.

• Medicare/Medicaid big change. Baby boomers drawing down

• Social security

• Subdivisions/developments gated by water resources.

• Question. As a manager, how do I manage the people side of these kinds of changes.

Framework of change:
Why, what, who? Are we changing.

If we can’t get the people to achieve the change then we can’t be successful.

The gating factor on change is no longer technology (has it ever been? Chris) – it is people’s ability to handle/absorb change.

If our success in technology is gated by our ability to manage the people side of change then we had better figure it out. It was very disappointing to see in the target audience here at the Gartner conference how little effect current change management initiatives have had.

Key points are that as we knew, Executive sponsorship of change is vital. However executive sponsorship isn’t just “show up for the kickoff and sign the checks”. It really must embody active involvement. Even more worrying is that, again in the audience at the session, that most attendees don’t have a “structured approach”, nor proper communication plans.

It has been our experience that change management is viewed by the technical teams as “touchy feely, unnecessary, gets in the way.” Changing that perception is a change management in its own right. That being recognized, the whole “Awareness, Desire, Knowledge, Ability and reinforcement” cycle. The presenters thesis is that all change goes through this cycle. So if we attempt to encourage the technical teams just by giving them Knowledge, we are entering the cycle too early. We need to find ways to get Awareness and Desire enshrined.

Keynote...

Notes from Roy Schulte’s session on Event Processing.

The big key here is that Gartner are positioning EDA and Client Server (Request/Response) as subsets of SOA. We use many of the same concepts (standards based, abstracted, etc.) in both of the models. Event Driven Architecture is, however, better placed for situational awareness. Much of what Roy had to say was around the handling of Complex Events – typically described as aggregations of simpler events. He also made the key observation that an event stream can, of course, kick off a number of action streams. Using an airline example where as a result of some event data being received a whole raft of operational processes is triggered – from scheduling catering to preparing the ramp.

It is also clear from Roy’s remarks that even though we had the message oriented movements of the 90s, Event processing is still emerging. The usual innovators (financial institutions especially) have jumped onto this paradigm because of a combination of regulatory needs and some major competitive advantage in an environment when market analysis in milliseconds is now the norm.

BAM – Business Activity Monitoring leading to “real time BI” or genuine situational awareness is fast becoming a real possibility when event processing approaches are applied.

Gartner Coverage!

For all the MomentumSI coverage at the Gartner show, please visit our corporate blog:

http://www.momentumsi.com/blogs.php

Gartner Conference - SOA

MomentumSI will be sponsoring and participating at Gartner’s Application Architecture, Development & Integration Summit taking place this week in Orlando, Florida. This is a significant milestone for SOA as it represents the 10th anniversary of the AADI Summit…the underlying theme being “How to deliver value in a fast-changing SOA environment”.



Our Enterprise Architecture Solutions team will be on the ground at the summit and interacting with the architects, application managers and analyst in attendance. We will be posting daily blogs regarding the hot topics encountered and engaged discussions across SOA, application and Web infrastructure… stay tuned!

The Worst SOA Presentation I've Ever Seen

Jean Jacque Dubray is outraged. He declares:

"I watched Jim (Webber) and Martin's (Fowler) presentation tonight before I went with the kids see Kung Fu Panda. The two furious have given a presentation that's got to be by far the worst presentation on SOA I have ever seen, it is not even pathetic, it reached the level of Sadness. If you wanted to turn off customers you couldn't do it better. "

I watched it. It sucks - but I've seen worst. Jim and Martin keep talking about why we shouldn't buy an ESB. The early ESB's were largely just JMS products and proprietary. In addition, the vendors positioned the ESB as the center of the software universe rather than a valuable component that has a specific function. However, the concerns I voiced five years ago on this subject have largely been addressed. Regardless, I'll agree with Jim and Martin that the ESB has the potential to do harm if over used or used incorrectly (but this is true for just about everything).

Here's my beef with the presentation. Other than the lame attacks they did on the acronym SOA, they failed to present a solution to the problem they introduced: Attacking Silos of Systems. Jim and Martin avoid this issues completely. They basically say "use our stuff from 7 years ago and you'll be fine". This includes refactoring, continuous integration, test-driven development, dynamic languages, etc. Let's be clear, these are excellent concepts that all moderns software development groups should use (if they aren't already...) but it has virtually nothing to do with the problem at hand.

If you look closely at the pitch, they fail to discuss how to not create multiple silos in the enterprise, let alone how to remove the ones that exist today. Their approach is "program better" and "increment". Fowler is an icon of modern computing and the concepts that he championed in the late 90's were brilliant. However, this stuff is crap. The promotion of "use a dumb network" and "use agile techniques" are things SOA guys agreed on 8 years ago. It's a "no shit, Martin..." kind of thing.

Now, tell me how you're going to solve the silo problem. Attacking SOA with your Same Ole Agile crap is a non-starter. These guys will have to address the real problem and quit pushing their old books. Life sure would be easy if we could all just "do REST" and then call SOA a success.

McGovern on EA-Joke

In a recent post, James "fully insured" McGovern disputes my criticism of enterprise architecture. Mostly, he was disappointed that I went after Zachman, suggesting that EA's just don't care about that anymore (which I agree). I'll add that many of them feel that FEAF and TOGAF are also a bit too 'fluffy'.

But unlike me, James seems content with the state of his Visio and Powerpoint tooling, suggesting that he and his colleagues are doing just fine.

And on the subject of "silo funding", James states, "Funding models should never look like enterprise architecture and besides they are managed by two different entities..." I'm not sure what that means. My point is that the funding model should align with your business strategy. If the strategy is to provide a seamless experience for a customer as they cross through the silos, then the funding should reflect that priority. Without proper funding, EA's become security guards with a flashlight and no gun.




BUT - the thing that struck me the most about his post was that he never actually defended the enterprise architecture discipline. This could be that he feels that it doesn't need defending. Alternatively, he could have his own frustrations with the discipline. So James, which is it?

WOA wasn't important to me last week

I spent last week working with a couple of my enterprise customers. The time was focused around the Shared Service Center (formerly known as the SOA Center). Here are the big issues that we worked on:

- Improving the help desk for production implementation problems related to shared services

- Improving the ability to perform root-cause analysis for service exceptions

- Getting funding to pay for a better staging environment

- Changing the way we engage with large I.T. programs so that they don't get bombarded by 5 different CoE's

- Changing our 'service discovery' process to make it easier to project ROI for shared services

- Identifying a new set of processes that support organizations will have to follow if the business application requires high availability: "Gold, Silver, Bronze SLA"

- Modified and communicated changes to our "Service Architecture Document" in order to provide consistency in documentation detail

In my world, SOA refers to the organizational politics necessary for an I.T. group to perform their job efficiently.

SOA has evolved from 'web services' to 'an architectural style' to 'an enterprise architecture framework' to 'a specialized I.T. lifecycle and supporting organizational design' - to 'all of the above'.

If WOA wants to encompass the aforementioned activities - I want in. Until then, WOA is just a cool thing for analysts, press and marketers to talk about. Debating the HTTP verbs might seem like 'real architecture' to some but I am genuinely concerned that a 'shiny object of misdirection' is taking our eye off of the real problems.

WOA wasn't important to me last week and it won't be next week.

Is Your Programming Paradigm HOT or NOT?

Is your programming paradigm Hot or Not????

Well, you might not agree with my observations, but here's what I'm seeing:



Real Time
Let's start at the bottom of the stack: Real Time. Due to an increase in consumer devices, wireless networks, etc. we are seeing additional requirements for new low level programming. I wouldn't call it 'explosive demand', but the area does seem to be growing.

3GL
Surely, I'll get beat up here... but that's life. I am of the opinion that the amount of 'straight 3GL' coding continues to decrease. With the maturity of other paradigms people don't need to do as much old fashion hand coding as they used to. The bulk of this work has moved up a layer in the stack (3.5 GL / App Dev).

Application Development
These days more and more people write their applications on top of some stack (Java EE, open source frameworks, .Net, etc. Typically, they are using a combination of a 3GL with DSL extensions (JSP, ASP, etc.) In recent years, we saw the big application platforms (ERP, CRM, etc.) get (mostly) migrated to one of the aforementioned stacks.

Package App Customizations
The ERP, CRM and other packaged app vendors have increased their market share (as a percent of the enterprise footprint). This has moved traditional application development to more of a 'customization' model. Power users or application configurators use a workbench to add fields to a screen, modify reports, grant user access and other basic operations. New modules or complex changes are still typically done with more of an Application Development model except that the developer is expected to use the 'business framework' that comes with the system.

Platform as a Service
Although PaaS remains in it's infancy, it is growing at a rapid pace. From a language perspective, we seem to be seeing three options:
- The first option is to create a new language (like Apex) that is PaaS friendly (multi-tenant, sandbox, governed, etc.)
- The second option is to take a current programming language and throw exceptions with people call potentially harmful features (like Google did with their Python impl)
- The third option is to let the developer program in any language they want and let them deploy it on a VM. Here, developers are typically charged for CPU time and the VM is the sandbox, thus they don't really care what you do.


In general, we're seeing more and more development move up the stack. On occasion, we have to rework the stack, so we drop back down into lower layers and then work our way back up. Ultimately, the stacks get figured out and dollars (and work) flow into the layer of the stack that is most productive.

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.

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