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?