SOA Matters / The Cloud Matters

Dispelling Common Cloud Myths

Kyle Gabhart — Tue, 02 Feb 2010 22:29:39 +0000

Over the past 6 months I have been working with a lot of clients that are either exploring the potential of Cloud Computing, or actively engaging in Cloud initiatives. As I have worked with these organizations and had countless whiteboard discussions with curious individuals, I have noticed some very common misconceptions regarding Cloud Computing.

Myth #1 – Cloud Computing is really just virtualization with a web-based interface put in front.

Reality – Cloud Computing designs often rely heavily upon virtualization technology, but encompass a much broader set of supporting technologies.

Cloud Computing solutions are rarely implemented without virtualization, but do not explicitly require resource virtualization.
Cloud Computing supports a broad set of business cases (cloud dekstop, cloud service, cloud software, cloud storage).
Cloud Computing delivers solutions via an elastic, utility computing model (pay per use), shifting fixed costs to variable costs.
Cloud Computing supports loosely-coupled integration techniques through the use of standardized Web service interface technologies.

Myth #2 – Cloud Computing is just a new term for Grid Computing.

Reality – They are similar in their efforts to optimize resources and support smooth scaling of capacity, but they are nearly opposite in their objectives.

Grids are designed for one user to have all resources. Clouds are designed for one user to have a fraction of available resources.
Grids are designed to carry the notion of federation to the “nth degree”. Even ethernet connections are federated. If this design strategy were applied to a Cloud, it would result in a colossal policy challenge to disentangle as multiple users compete for resources. Clouds are designed to virtualize and abstract a portion of resources in order to support elastic demand and scalable solutions.

Myth #3 – Cloud Computing is just the next generation of Application Service Providers (ASPs) in the form of Software As a Service (SAAS) like Salesforce.com, Web-based Email, Twitter, and others.

Reality – Cloud Computing supports various design strategies and business cases, with SAAS being a common but not exclusive model.

Multiple Cloud service models exist, including Infrastructure-As-A-Service (IAAS), Platform-As-A-Service (PAAS), and Software-As-A-Service (SAAS)

Myth #4 – Cloud Computing is basically Service Oriented Architecture (SOA) sitting on top of Virtualization.

Reality – Clouds tend to incorporate service-oriented architectural principles, but incorporate additional considerations beyond the scope of most SOA environments.

Cloud services have added requirements to support configurable / declarative data storage, configurable / declarative security, as well as interfacing with cloud controllers and/or agents.
Clouds tend to leverage SOA design patterns, interface and messaging standards, and service policy enforcement mechanisms.
SOA carries with it proven governance and service portfolio management strategies and supporting toolsets that Cloud solutions can utilize.

Myth #5 – Cloud Computing represents a huge security risk, exposing critical enterprise resources and valuable intellectual property in the public domain.

Reality – Not all clouds are created equally.

Private clouds can be constructed behind a company firewall, in which an enterprise-level organization serves as the cloud provider for various divisions and business units.
Public clouds can be used selectively, moving sensitive data to the cloud and/or moving processing blocks to the cloud out-of-context so as to off-load their processing without revealing their usage.
Many organizations house data in 3rd party data centers today and are reasonably confident of the providers security measures, storing data with a Cloud provider could be handled in much the same way.

Going Right to the Source

Kyle Gabhart — Tue, 21 Jul 2009 14:45:26 +0000

In-source, out-source,
up-source, down-source,
crowd-source, cloud-source,
source, source, source.
At your work and on the street,
how many different sources you meet!

(Inspiration borrowed from multiple readings of Dr Seuss’s The Foot Book to my toddler).

It seems everyone these days is looking for a new ’source’ for making their business, civic organization, or personal life more efficient and/or more manageable. I see two primary motivations for this trend:

There is a seductive and ever-strengthening pull to join “The Cult of the New”
There are genuine market pressures as well as social and economic dynamics that are solved by optimizing resource utilization

At this point, I am tempted to just end the discussion here and farm (code for ’source’) the rest of this post out to the blogosphere and let all of you solve it (I’m a fan of irony). But I think I’ll go ahead and expend a few more brain cells and actually try and make a coherent argument of my own first.

The Cult of the New

If a technology, methodology, or other ‘-ology’ has two or more of the following criteria: shiny, has acronyms associated with it, has a magazine with the name in the title, has a conference dedicated to it, etc., then it is ripe for hype and for drawing people toward it out of the sheer momentum that it is THE thing to do!

The momentum around ’sourcing’ and in particular, cloud-sourcing certainly falls victim to this in many respects. It is important to realize that the problems we have today as well as the solutions to those problems largely remain the same. It’s not to say that there is nothing truly innovative, but it is to say that often times we repackage or even just rediscover a way of solving a problem and it is simply called something different or is applied at a different level of abstraction than it was when it was originally introduced 20 or 30 years ago.

There are genuine opportunities around sourcing / farming / distributing work across various resources. But there are also real-world risks associated with doing so. I’ll be exploring both of these themes in a webinar tomorrow afternoon. (Wednesday - July 22nd starting at 12PM EDT) - “Risks and Opportunities with Cloud Computing” I hope you are able to join in.

Resource Optimization

I certainly don’t want to give anyone the impression that sourcing needs out or offering capabilities in a flexible, distributed, even utility service fashion is necessarily a bunch of noise. I do believe that there are genuine market pressures and economic realities that drive organizations of all shapes and sizes toward some sort of creative sourcing model. Bruce Barnes supplied an excellent analysis of this in a CIO Update article earlier this month - “Smart Sourcing: The New Normal”. Bruce focuses upon effective vendor / partner management in this new world of smart-sourcing and he outlines 6 steps of managing this effectively.

In addition to effective vendor management, there are some essential steps that must be taken internally within the organization in order to truly manage resources and the sourcing of work effectively. It all begins by taking several giant steps back and evaluating your business drivers to ensure that you are pointed in the correct direction to begin with. From there, you must embark upon a process of discovery around internal needs and capabilities, external resources, provider service levels, resource utilization metrics, and comprehensive enterprise portfolio management.

If adopting a cloud computing or similar multi-sourcing model of problem-solving is something you are considering, you may want to take a look at a post of mine from earlier this year (Adopting Your Very Own Cloud) where I explore pragmatic steps for evaluating and potentially adopting such an approach.

Cloud Computing Cloud Expert Cloud Value Cloud Computing ROI Cloud Training Cloud Consulting In-source Out-source Cloud-source Cloud Adoption Smart-source

Is a Picture Still Worth 1000 Words if You Don't Understand the Language?

Kyle Gabhart — Mon, 11 May 2009 21:36:07 +0000

Modeling business processes offers an effective way of capturing end-to-end requirements for a solution. It also clearly communicates the business scenario and corresponding solution in a way that can be understood by both business and technology professionals. This communication does hinge upon consistency in modeling, output format, and even the approach that is used.

In working with various organizations on their process modeling efforts, I have come across a common problem. Organizations tend to have a wide degree of variation in modeling approach and symbology, resulting in confusion and lost productivity.

I have compiled the following guidelines, aimed at assisting organizations of all shapes and sizes with approaching process modeling in a consistent and non-ambiguous fashion.

- Choose a single tool for use in process modeling.

- Use a standard such as Business Process Modeling Notation (BPMN) to provide a consistent set of symbols for describing your processes.

- Identify and document a common symbol library to be used with process modeling (even BPMN-compliant processes can be interpreted differently). The symbol library should include list of symbols as well as definitions for how they should be used. For example: How will asynchronous actions be represented? How will sub-processes be represented? How will looping process flows be depicted? and etc.

- Provide a text narrative (possibly a formal business use case) to describe how each process model works. This provides a description of the process that may convey assumptions, conditions, and standard execution flow details that otherwise may not exist or may not be obvious in the process model.

- Consider crafting a big picture view for how all processes work together. This could be an enterprise portfolio that places processes in context or a sort of activity diagram that shows the hand-off and interaction of various processes.

- All process models should have a noun and a verb in their name, not just a single word. For example: Rather than ‘Order Process’, you might have ‘Order Resource Process.’ Rather than ‘Schedule Process’ you could define a ‘Schedule Event Process.’

Modeling business processes provides a valuable, visual artifact that enhances project communication. It does, however, hinge upon a critical assumption that the model will be interpreted in an unambigious fashion. By following a handful of modeling best practices, organizations can improve the consistency of their models and promote clarity in interpretation.

Cialis generic brand name differences

Cialis taken by women in europe

Cialis liver disease

Cialis tadalafil cialis tadafil tal

Cialis pills manufacturer

Cialis vs levitra faq

Cialis istanbul

Cialis name brand cheap

BPM BPMN Process Modeling SOA Business Process Process Modeling Best Practices SOA Best Practices

Juggling Multiple Data Models with Services

Kyle Gabhart — Tue, 03 Mar 2009 18:31:30 +0000

Recently, a client approached me with a quandary. When designing XML schemas for Web services, how do you balance the desire to use industry standards such as UBL ( Universal Business Language) or CICA ( Context Inspired Component Architecture) to support data interoperability with the unique needs of particular domains and sub-systems within the enterprise? The client’s service design team is rightfully concerned with the competing interests of internal enterprise standardization, interoperability with external entities, and addressing the unique needs of local domains and process constraints. How can these competing needs be effectively managed when designing the schema for a given service?

The Standard Answer

Naturally, you start by giving the standard answer - “it depends”. This is an essential and carefully crafted phrase that all consultants are taught to give according to page 17 of How to Win Clients and Influence Budgets. Of course, the standard answer is rarely sufficient, but it is not without merit. It is certainly true that the decision regarding your data model design depends significantly upon a host of factors:

Which use cases are high priority?
Which use cases are high impact (to stakeholders and/or to customers)?
Which systems and/or processes are mission critical?
Are you including industry standard data models in you enterprise out of necessity (i.e. ONLY when you are forced to interact with other entities), or is it part of a broader modernization effort within your organization?
Do interoperability challenges or integration challenges currently contribute most significantly to your development and/or maintenance costs?
Which interaction scenarios are of higher priority, internal or external service calls?
Would aligning more closely to one of the available models lead to a significant reduction in data mapping activities or is the environment simply too fragmented to support this?
Is there one particular system or business process that is unique and skewing perceptions regarding our service data models?

While all of these questions (and many more) are important and aid in facilitating a thorough examination of the problem, we rarely have the time to examine each problem from all possible angles. Consequently, we must look toward guidelines and rules of thumbs.

Guidelines for Managing Multiple Service Schema

1) Your business processes should only work with a single data model if at all possible. Business processes are best designed to be data model agnostic and operate off of an internal, process-centric model. I explained the importance of process-centric data models in a previous post.

2) Your services should work with as few data models as possible (one model being preferable). This is just good commonsense. For each data model that is added to the mix, your development time and long-term maintenance costs increase at a non-linear rate. The pain will intensify and it will do so rapidly with each new model you add to the mix.

3) If your services are going to work with multiple models, you should put some sort of taxonomy / categorization scheme in place to distinguish the data models used by services. For example, services that are outward facing might use a data model accepted more broadly by the industry. Services used by a particular LOB might use a certain data model, and services used by another LOB might use another. Another distinction could be infrastructure services vs data services vs application services. Regardless of the approach, there needs to be some methodology that is objective and governable for when one data model is used vs when another data model is used.

4) Data model transformation is a necessary evil. It should be done only when necessary and you should contain the transformation to a designated component. Transformation activities should be handled by intermediaries (data services, ESB, network appliance, other mediation framework) when possible rather than building it into the internals of a service or process. This keeps your services clean, provides a nice reusable transformation mechanism, keeps your interoperability more loosely-coupled, and provides for agility and extensibility in the future.

Juggling multiple data models within a service oriented environment is no one’s idea of fun. When possible, aim for a more comprehensive and strategic analysis of the environment (see the ‘Standard Answer’ outlined above). When this is not realistic, try to use the above guidelines and rules of thumb to help you tactically navigate the murky waters of data model incongruity. Service design isn’t easy, but it doesn’t have to be rocket surgery either. Best of luck!

SOA SOA Expert SOA Data Modeling SOA and MDM MDM Canonical data model Service design schema design SOAD

Adopting Your Very Own Cloud

Kyle Gabhart — Wed, 18 Feb 2009 23:12:47 +0000

You and your team have had your heart set on achieving scalability, availability, reliability, and economical efficiency for some time now. Over the years, you’ve tried everything you can think of to achieve these goals.

A Journey of False Starts

This is not the first time you’ve had your heart set on revolutionizing your information systems:

One year, you rolled out a big Enterprise Application Integration (EAI) initiative, but it was too brittle and carried high maintenance costs.
For a while you experimented with Web Services, but found that while they were easy to work with, they were largely insufficient to meet your broader needs due to a lack of architectural design guidelines.
Out-sourcing, in-sourcing, up-sourcing, down-sourcing, and cross-sourcing just seemed to shuffle the work around and tended to result in the blame-game.
You’ve bought every pill and tonic you could find (ESBs, network appliances, UDDI registries, load balancers, etc.), each with varying degrees of success.
One crazy weekend you deployed a full-scale dynamic rules engine to fully automate decision logic, but this carried hidden costs and fell short of your expectations.
Then you stumbled across this witch doctor who could abstract data, memory, processing power, and bandwidth through some wizardy known as ‘virtualization’. While initially very promising, the startup costs and expertise required were obstacles that you simply could not overcome.

On the verge of losing all hope, you hear that this virtualization thingy might not have to be so expensive after all thanks to Cloud Computing. Could it be? Could you actually achieve your dreams of scalability, availability, and reliability, without giving your CFO a heart attack?? Could you actually adopt a Cloud of your very own?

Adopting Your Very Own Cloud

Adoption can be a scary process. In your fear of doing something wrong, you may be tempted to buy a big, expensive consulting package and just have someone else handle everything. You don’t need to do that. Simply find a subject matter expert to serve as a mentor that can guide you through the process of pragmatically evaluating and possibly even adopting Cloud. Along the way, make sure that this mentor is educating you and your team so that you are able to function effectively once this person has left the building.

Ten Steps to Successful Cloud Adoption

Identify your business drivers — What are you actually trying to accomplish from a business perspective? What are your enterprise initiatives, key objectives, and targets? Look for growth drivers as well as risk mitigation drivers.
Get educated — What business opportunities does Cloud Computing present? What are the advantages, disadvantages, and key factors that Cloud brings to the table? What cost models, value models, solution architecture, and infrastructure design changes are required in order to take advantage of Cloud Computing? What impacts does cloud have at the enterprise, division, and individual project basis? Throughout the adoption process, your mentor should provide education around Cloud, but at this stage you need focused attention upon the subject.
Articulate a value proposition — How do you see Cloud Computing supporting one or more of the drivers identified in the first step? There are a variety of reasons that an organization might choose to adopt Cloud (reduce maintenance costs, scale support costs during peak system usage, support after-hours service requests, business continuity, operational risks, reduce capital expenditures, accelerate growth into new markets, improve business agility, and etc.). Identify and clearly articulate the Cloud value proposition(s) for your enterprise that are applicable given your business drivers.
Define one or more scenarios — With an understanding of the value propositions that you are targeting, it is now time to get specific and define scenarios or use cases for applying Cloud Computing to address one or more of the business drivers previously identified. These scenarios will serve as candidates for the initial Cloud adoption effort that your team will embark upon later in this process.
Produce a roadmap – Using an “as-is” and “to-be” modeling technique, identify the gaps that exist between the current state of your enterprise and the desired future state for capitalizing upon Cloud. Next, define a roadmap that shows how to move toward that cloud-enabled future state. It is critical that this roadmap include objective and measurable milestones for your organization to work toward.
Gain stakeholder buy-in — Throughout the adoption process, you will need to gain buy-in from various groups regarding this initiative. It is particularly important to do-so after defining the roadmap and prior to actually moving forward with it. From this point on your team will be drawing upon enterprise resources to establish governance, infrastructure, project personnel, and then deploying real solutions into production. It is crucial that all impacted parties are on-board and ready to go.
Establish governance — Oh great! Here we go again! Why does everyone insist that we need to govern our business initiatives? The answer is simple - people screw things up. Governance ensures that we are all playing from the same playbook (vocabulary, portfolio, models, architecture, standards, metrics, etc.) and that the enterprise’s target objectives and risk factors are duly consider and investments are protected. Governance should be lean, focused, and ever-present.
Invest in infrastructure — Depending upon your adoption strategy, this may be very significant (server farm, policy manager and enforcement mechanism, load balancer, ESB, cloud gateway, etc.) if you are going to develop your own internal cloud or relatively simple (content-based routing proxy and possibly a service registry) if you intend to leverage an external cloud vendor.
Cloud pilot — The metaphor of a test pilot has been used consistently used for years to describe initial work done in a new area. The fact that we’re now piloting through clouds opens up a whole new set of possible puns to play around with. Setting those aside, the importance of proving out a single, definable test case that can prove out tangible value for your enterprise is essential. As with other pilot initiatives, it is important that you carefully select from a candidate set of possible projects. You need something big enough to count, but small enough to be successful. Your cloud mentor should assist in this process.
Enterprise roll-out — Provided that the pilot was successful, it is now time to move foward with the roadmap and look for additional opportunities to apply cloud solutions. This may involve moving existing solutions to the cloud, consuming cloud services, or delivering brand new capabilities that have never existed. Continue to expand the use of cloud within the enterprise so long as your solutions adhere to the governance guidelines that have been established, and they are consistent with your overall business drivers for the enterprise.

Cloud computing holds tremendous potential for both small and large organizations. Adopting your very own cloud solution may seem daunting, but the maturing of service oriented patterns, practices, methodologies, and tools has brought cloud well within reach. With proper guidance, your organization can evaluate the potential for cloud and pragmatically adopt it without breaking the bank.

Owning Hardware is soooooo 2008

Kyle Gabhart — Fri, 06 Feb 2009 17:00:57 +0000

As the fallout from the economy takes it’s toll: staff layoffs, reduced capital expenditures, dwindling revenue, etc., enterprises of all sizes are looking for opportunities to trim back on their fixed costs and move toward business models that are more agile, scaling up AND down with demand. Call it Cloud Computing, call it Service Oriented Architecture (SOA), call it service orientation, or just call it good business.

A couple of days ago, Fortune magazine observed this trend in their Tech Daily post: “Goodbye hardware. Hello, services”

The core of the article can be found in a quotation and subsequent summary statement from the article’s author:

“As Salesforce CEO Marc Benioff said back in November: In this economy, ‘customers are not going to bring out their checkbooks for the cost and risk and complexity of big database purchases, or application server purchases, or data center purchases.’ They’re buying more services, and fewer servers.“

The article sites such data points as declining earnings for PC and server manufacturers, strong growth in the services and SaaS arena, and a huge jump in IT outsourcing initiatives (a key business driver for Cloud Computing, as I described previously: Real Value in the Clouds).

That’s two Fortune articles this week on Cloud. Good work mainstream media!

Cloud Computing Cloud Expert Cloud Value Cloud Computing ROI Cloud Training Cloud Consulting

Real Value in the Clouds

Kyle Gabhart — Wed, 04 Feb 2009 17:31:16 +0000

I have officially come full circle from my position last summer regarding the reality of Cloud Clomputing in which I presented a skeptical view of Cloud’s potential to actually materialize. It is now quite apparent to me and increasingly to my clients and readers, that Cloud is real and it is here to stay. I was reminded of this reality just this morning. As I read through various news stories online, I came across the following fascinating story from Fortune Small Business - Cloud Computing: Supercomputers for Hire.

The article clearly articulates a real life value proposition for TC3 Health. When faced with a massive increase in demand for a new service that TC3 was offering, they turned to Amazon’s EC2 service to handle the overflow of demand. Thus the scaling, failover, and reliability concerns were all neatly outsourced to a 3rd party and TC3 only had to pay for usage (not installation and on-going maintenance). The results speak for themselves.

“Now TC3 Health spends a mere $600 a month on EC2 fees, including customer support. That’s $29,400 a month less than what it would have spent on physical servers. The company’s revenue rose to $20 million last year, which might never have happened had TC3 not reached into the cloud.”

Maybe the clouds really are lined with silver…or there is a pot of gold at the end of the rainbow…or whatever silly metaphor you’d like to use. The bottom line - Cloud Computing works.

Cloud Computing Cloud Expert Cloud Value Cloud Computing Case Study Cloud Computing ROI Cloud Training Cloud Consulting

Cloud Computing Primer

Kyle Gabhart — Wed, 04 Feb 2009 17:07:18 +0000

Unless you have been under a rock (hiding from the depressing economic news, no doubt), then you know that the industry is buzzing with interest around Cloud Computing. Due to the extraordinary degree of interest and constant questions regarding Cloud that I have seen from my clients, I thought it might be good to provide a quick primer and link to some helpful resources.

Cloud Computing 101

Definition: Delivering services and capabilities to systems or end users in a diverse network environment with the ability to abstract or even outsource infrastructure concerns such as data storage, network bandwidth, or even resource availability.

Telecom Analogy (describes the availability facet of cloud): Landline telephone service introduces various single-points of failure (the provider, physical cable from your house to a hub, the connection in your home, etc.). Cellular telephone service relies more upon a cloud model (seamless support wherever you travel, if your provider has no tower or a tower goes down you can use another provider’s tower seamlessly).

Dining Analogy (describes the on-demand facet of cloud): The Cloud Dining Analogy was first articulated by Omar Sultan here. The essential argument is that the service of cooking can be supported very flexibly (cook at home, order take-out, dine at the restaurant), and you can change your mind on-the-fly based upon the available resources in your pantry or the cleanliness of your kitchen.

Four Key Questions

Everyone has in mind some variation of the following four questions that must be answered regarding Cloud Computing:

Where did Cloud Computing come from?
What is so special about Cloud Computing?
Why does Cloud matter?
How can my organization explore Cloud?

I delivered a webinar yesterday, The Role of Cloud in the Modern Enterprise, to address these four questions. If you didn’t get a chance to attend, please feel free to download the presentation deck.

Additional Resources

Educational

Technical

Business

Cloud Computing Cloud Expert Cloud 101 Cloud Primer Cloud Basics Cloud Training Cloud Consulting

SOA and The Year of the Ox

Kyle Gabhart — Tue, 27 Jan 2009 23:46:10 +0000

Communities the world round celebrated Chinese New Year yesterday. 2009 is the year of the Ox, and with it comes new insight and possibilities into what the year holds for our world. According to Chinese tradition, the year of the Ox represents “prosperity through fortitude”. The Ox symbolizes that success will come to those that buckle down, dig in, and persevere through hardships. In contrast, 2008 was the year of the Rat. The Rat symbolizes pioneering, cunning, ambition, and even a sense of entitlement. There is a time and a place for everything, and the time for the rat and the need for the ox has certainly come. Given the economic climate and the state of companies, governments, and organizations of all shapes and sizes, this is an apt and timely metaphor.

2008 was an exciting time for exploration and pioneering possibilities. SOA adoption was in full swing, the virtualization discussion morphed into Cloud computing and took a prominent degree of mindshare in the process, and the Web 2.0 momentum transformed into an emphasis around enterprise mashups. 2009 presents a very different reality. The time for pioneering and cunning must give way to the much more pragmatic and focused intensity symbolized by the ox. It is time to buckle down, dig in, and solve real-world problems with SOA and its related initiatives.

Ox-inspired Tips for Success with SOA in 2009

If you don’t have a real business case, you have NO business pursuing SOA. Moreover, the business case should lead you to select SOA rather than selecting a business case to justify your decision to adopt SOA.
Invest in SOA selectively this year. Education and re-skilling will yield results almost immediately. Governance investments will also bear fruit fairly quickly. Investments in tools and infrastructure should be closely scrutinzed. Over-hauling your high priority, mission-critical systems might be too risky (and expensive) at this point. Developing an Enterprise Architecture (EA) framework and moving your enterprise to a canoncial data model might be best to put on the back burner for now.
Cloud computing offers some really compelling possibilities, but the increased buzz around Cloud is hardly enough to warrant special attention. There have been no revolutionary standards, tools, or platforms made available that have recently changed the game. If you weren’t looking into virtualization, grid, or SOA before this year, it probably doesn’t make a lot of sense to launch out into Cloud right now.
Develop fewer services that each provide clear and measurable value to the enterprise rather than developing a broad array of services in hopes of providing a catalyst for progress and innovation.
Architectural layers and governance oversight must be value-added. There are no bonus points for adding a service layer or additional governance requirement in the absence of a tangible value (this holds true for all project aspects, but architecture and governance are common culprits for excess).
Develop services that meet their service interfaces. Nothing more, nothing less. This is always good advice, but the Ox reminds us how critical it is to avoid scope creep in the form of gold plating.

Opportunities exist for service orientation and the array of related initiatives (SOA, SaaS, Cloud, Mashups, etc.) in 2009. The key is to ensure that real business value is driving your initial and continued adoption efforts, that you invest in education, and continue to prioritize governance to keep everyone focused on the goal.

The current economic climate and corresponding budgetary pressures are a sober reminder that the extravagence and excess over the past couple of years cannot continue indefinitely. As companies announce layoffs and organizations around the globe rein in spending, it can be discouraging. There is, however, a silver lining. The Ox does not symbolize survival through fortitude, but rather prosperity through fortitude. Invest cautiously, move forward with service orientation pragmatically, and you can certainly come out ahead in 2009.

The future is bright.

Be the change.

SOA SOA Expert Cloud Computing Web 2.0 SOA adoption SOA success Service Orientation SOA Methodology SOA training

SOA’s not dead yet…it’s getting better

Kyle Gabhart — Thu, 08 Jan 2009 02:59:17 +0000

All across the blogosphere, analysts, experts, and technology enthusiasts are buzzing about the latest claims that SOA is dead. The thunderstorm of controversy was set off by Burton Group analyst, Anne Thomas Manes, who recently blogged an obituary for SOA entitled: SOA is Dead; Long Live Services. As I consider the bold claim of SOA’s death and square it with the dozens of clients that I have worked with on various service orientation initiatives throughout 2007 and 2008, I can’t help but think of the “Bring out your dead” scene from Monty Python and the Holy Grail. I can just hear the personification of SOA pleading with Miss Manes: “I’m not dead yet…..I’m getting better.”

The ‘obituary’ begins as follows:

“SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”.”

Manes goes on to describe SOA as a “failed experiment” in which some companies invested millions with almost nothing to show for it. In fact, she states, in some cases the enterprise is in a worse state:

“In many organizations, things are worse: costs are higher, projects take longer, and systems are more fragile than ever. The people holding the purse strings have had enough. With the tight budgets of 2009, most organizations have cut funding for their SOA initiatives.”

Throughout the interesting and entertaining read, the post makes four essential claims:

SOA did not live up to its promises
The term ‘SOA’ has a negative connotation and evokes backlash
The need for services and service orientation is stronger than ever
Success requires transformation

Claim #1: SOA did not live up to its promises. I’m not sure exactly what SOA promised, but I am well aware of what many CIOs/CTOs promised their boards and I am well aware of what various vendors and consulting organizations promised. Each of these groups had their own agendas and motivations, but the result was the same. They made outlandish promises and viewed SOA as some sort of magical panacea. So the problem is with the expectations that were lumped in with the term ‘SOA’, and not with the actual viability of an architecture that is service oriented. This naturally leads us to the next claim regarding terminology and backlash.

Claim #2: The term ‘SOA’ has a negative connotation and evokes backlash. In my experience, this is fairly isolated within particular companies and not representative of the industry as a whole. Anywhere that a CIO/CTO, consulting company, or vendor has run amuck has resulted in associating negative things with the term ‘SOA’. Moreover, I have worked with multiple organizations that openly refer to their initiative as SOA. I highlighted 36 companies spread across 5 market sectors with SOA success in my book. Finally, Joe McKendrick has kept a running commentary on his blog each December highlighting SOA success stories.

Claim #3: The need for services and service orientation is stronger than ever. Building off the frustration with the term ‘SOA’, Manes states: “Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.” She cites cloud computing, SaaS, and Web 2.0 mashups all as examples of the need for services and service orientation. It appears that her real beef is again with the term SOA and yet much of the article is spent talking about how SOA is out, yet services and service orientation are in. The trouble is that if you develop cloud services or web mashups without an architecture that is service oriented, what hope do you have of success? If service orientation and services are indeed essential, you need a comprehensive architecture to support such efforts.

Claim #4: Success requires transformation. Amen sister. This is so true. Anne says that the secret to SOA success comes down to a real commitment for transforming the organization and that SOA is only one part of that broader enterprise transformation. She eloquently describes the importance of this commitment when she states: “If you want spectacular gains, then you need to make a spectacular commitment to change.” So true.

What’s in a name?

A key theme throughout all of this is that the term SOA may carry with it some unfortunate baggage. I appreciate this point quite well. I made a plea to consultants and analysts last year as a panelist at the Open Group’s EA conference in San Francisco and then again via this blog (A Rose By Any Other Name) regarding the need to move past these labels and focus upon true transformation and problem solving. In the end, if we aren’t improving organizations and moving enterprises forward, then we’re just peddling the “next shiny IT thing”.

The case for a bright future

Disappointment regarding SOA’s ability to live up the hype and frustrations over terminology aside, I believe that the future for SOA is truly bright. Services are here to stay. Spin-offs such as SaaS, Web 2.0 mashups, and Cloud Computing confirm this reality. Service orientation is necessary, but not sufficient, for success with any of these initiatives. True success for enterprises deploying non-trivial service-based solutions must be backed by an architeture that is service oriented in nature. Dare I say…a service oriented architecture. Moreover, the maturity in the industry regarding SOA methodology, best practices, and tool support is at an all time high. Is SOA dead? Hardly. In fact, I’d say that it’s getting better.

SOA SOA Expert Cloud Computing SOA is dead Web 2.0 SOA adoption SOA success Service Orientation SOA Methodology