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...