Todd Biske: Outside the Box

Archive for the ‘SOA’ Category

Congratulations and best of luck to Brenda Michelson. She recently left her position with Patricia Seybold Group and introduced Elemental Links, Inc. To quote her blog:

Elemental Links is an IT consulting and advisory practice specializing in strategy, architecture, and portfolio planning for business-driven IT.

Brenda’s announcement got me thinking about the role of consulting in SOA adoption. For the record, I am not a consultant nor have I ever been a consultant, at least in the formal paid sense. I fall into the category of practicing Enterprise Architect like James McGovern and Mike Herrick. I would be an end-user of consulting practices. While I have many friends that are practicing analysts and/or consultants in this space, including Brenda, Jeff Schneider, and the ZapThinkers, Jason and Ron, they all tend to come out of the IT consultancy/advisory space. While there certainly is a market for this, and will be for some time, what is the right way to grow a business in this space?

The answer to this will largely depend on your view on whether SOA is an IT-driven thing or business-driven thing. We all know that a goal of SOA adoption is to render this a moot point. After all, IT is part of the business, isn’t it? While IT-Business alignment will continue to garner significant press for years to come, most would agree that SOA adoption should be about the business and not about the technology. Presuming things head this direction, what does this mean for SOA Consulting companies? Will they be competing for business with companies that provide assistance in adopting Six Sigma and other business re-engineering and improvement efforts? To what extent will these consultancies need to become specialists in different verticals, such as manufacturing, health care, financial services, retail, etc. in order to be successful? Will the marketplace shift to groups that have a more business-centric focus on technology, such as companies like Patricia Seybold Group and Elemental Links? Will SOA become more associated with business discussions than with technical discussions, or will some other term be used?

In my mind, the bigger problem is on the business side. There are lots and lots of consulting companies that exist that can author services in any desired flavor and platform. The real problem is in identifying what the right services are. There are plenty of case studies that have leveraged services for technical benefits, such as in a B2B integration scenario, but where are the case studies that are about SOA and BPM efforts leading to business change and innovation? Who are the consultancies that will make this happen? What will they look like 5 years from now?

I’d love to hear the thoughts of Brenda, Jeff, Patricia Seybold, and any others on this, in as much as they’re willing to share, since it certainly involves their business strategy. I’d also like to hear what other enterprise practitioners like James, Mike, Scott, Mark, and others have to say.

Technorati tags: soa bpm consulting six-sigma

We’re beginning to see some movement around vertical service architectures, or better put, the creation of reference service architectures for particular business domains. For example, back in April, HP had a press release announcing “Industry-specific Service-oriented Architectures.” Last week, on August 3rd, IBM announced the acquisition of Webify. Rich Seeley of SearchWebServices.com stated that Robert LeBlanc, general manager of IBM WebSphere Software, characterized a vertical focus as the next generation of SOA.

I remember back about 7 years ago when I was introduced to TogetherJ. A colleague had Peter Coad’s book, Java Modeling in Color with UML. Coad’s gave example models across a wide variety of business areas. While modeling the internals of the systems may not be as useful, as this is likely to vary widely by enterprises. What may not vary as much, are the services that expose the functions of the major components of the enterprise. This is where this new wave of vertical service architectures may have some legs. Companies will be free to implement the services however they want, but the identification of what services, at least some good subset to get started, are needed can be provided in the form of reference architectures. I’m not an industry analyst, so I don’t have the luxury of having seen many enterprises, but my gut tells me that if you compare two retail organizations or two health care organizations, the core services they require are going to be very similar. Differentiation can be made by the implementation of these services, the management of them, and the remaining 20% of services that aren’t typical of all organizations in that vertical.

This starts to imply that there is a range of commodity services that could have wide applicability and are likely not business differentiators, at least not in the sense that you have them. It’s more about how you use them. To that end, it would be great to see community efforts that address some of these domains. I’ve previously blogged about SOA for education. How many elementary, middle, or high schools do you know that have enterprise architects? How many of them even have any dedicated IT staff at all? Often times, it may be the computer instruction who is also acting as architect and operations support. My daughter’s school has a volunteer technology advisory board made up of parents with IT backgrounds that try to assist in the school’s technology efforts. I’ve logged many hours helping them with varied tasks like web site support and the installation of their WeatherBug station. Largely, however, all of the efforts are handled by Mrs. Lewis, who also happens to be teaching all of the kids about computers all day long. It would be great if we technologists, whether analysts, developers, architects, support, etc., could use of skills to help out in the community on these technology related items of our own good will.

Speaking of good will, James McGovern, is one enterprise architect who has posted a few times on giving back to the community, whether through his efforts to teach programming to high schoolers, or now to raise money for the Juvenile Diabetes Research Foundation. I applaud James for his efforts and encourage others to do the same. While it may not be development of vertical SOAs for medical research foundations, it’s still the right thing. I will make sure that the Juvenile Diabetes Research Foundation is on my charitable donation list for this year.

Technorati Tags: SOA, JamesMcGovern

Back at the end of June, I posted some of my thoughts on personalized services after the announcement of Google Checkout. At that time, a lot of my thinking was on how a service provider can personalize services for their consumers. Since then, my thinking has went in a different direction. In cases like Google Checkout, a third party is in the position of being able to collect and potentially share lots and lots of information about our shopping practices (no worse than what credit card companies already have).

What would be very interesting is if these service providers gave the true owners of the information the ability to control who and how could access it. This actually creates a very interesting scenario, and one that I think demonstrates the importance of the policy-based infrastructure now available for Web Services. Let’s suppose there is a competitor to Google Checkout called PayIt. PayIt is storing purchase information in their data centers. Let’s also suppose that PayIt can makes this information available to the shopping partners that are leveraging their checkout service, in either an aggregated or anonymous fashion. In reality, the owner of the data being shared is the individual shopper, not PayIt and not their retail partners. Google, however, is acting as both the data steward and the service provider. How does the data owner get involved? The data owner, you and me, sets the policies. While PayIt provides the service, we provide the policies that govern the service execution- who can access them, and what information they can see. Since most of us don’t work for PayIt, there needs to be a way to externalize the policy management from the service execution, even outside the firewall. While this is an extreme example, the same needs exist inside the firewall. The group that own the source code and deploy the services may not be the same group that sets the policies regarding who can access them. While today we have tools for externalizing authorization policies, we’ll soon need better tools for other types of policy management tailored toward the end policy manager which could be you and I.

Brenda Michelson has another good conversation going on her eBizQ blog regarding SOA and Agile Development. Here is my comment:

I fall in the crowd of classifying SOA and Agile Development as apples and oranges. I wouldn’t call it oil and water, because there are some things that agile development practices address that are directly applicable to SOA adoption.

First, my definition of SOA is always at the enterprise level. In my mind, there’s no such thing as an SOA project, only an enterprise SOA adoption effort. If I was on a project that was building both services and consumers, I think agile development would definitely be a good thing. The reason, however, is because by the nature of the project definition, the required collaboration should be in place to allow rapid change. At the enterprise level, however, the service provider and the service consumers are likely on completely different schedules, across many different projects and teams, all of which are barriers to communication and collaboration. Without communication and collaboration, agile efforts will struggle.

At the same time, creating rigid service interfaces that don’t change is completely the wrong approach. The problem is poor communication between service providers and services consumers, not an interface that changes. The business does not remain constant, and anyone who thinks that service interfaces can be defined once and set in stone is destined for failure. The key to success is change management. Change management is not a problem in agile development because of close communication between the parties impacted by the change.

So, I think the takeaway should be that SOA adoption must ensure that communication and collaboration between providers and consumers occurs. It doesn’t mean that service interfaces should change on a rapid basis, as individual component interfaces may on an agile development project, but it does mean that change should be managed.

I’ve decided that my blog needed some kind of name besides “Todd Biske’s blog.” While it certainly implies that it contains what I think, it doesn’t imply much about how I think. I originally thought about calling it “The Big Picture” but someone already has a blog by that name. I would call myself a big picture thinker before I’d call myself an “out of the box” thinker, but when it comes to SOA, a frequent message I give is to think out of the box, so it fits.

The above photo is of my youngest daughter at about 6 months old. I used this picture on a slide in my very first external presentation which was on SOA. I think that thinking outside of the box is an inherent part of adopting SOA. No matter how much strategic planning has gone on, and how much context is given, as soon as things get turned into a project, the project plan takes over and the more strategic needs go on the back burner. It’s important to keep thinking strategically while acting tactically, always taking steps toward continued improvement in the enterprise. If you don’t have someone whose responsibility it is to think outside of the box, you’ll probably have a much longer road ahead of you.

I was listening to the CIO Daily News Podcast this morning and their report on Google Checkout and it got me thinking about privacy and personalization. The first thought running through my mind was that this could be a gold mine for them with their advertising model. While I don’t know the details of how it works, it is possible that their service could have visibility into not only how much money you spent and who you spent it with, but all of the products you purchased, as well. The key to the whole advertising model is targeted advertising. With the ability to see this, even if it winds up being no more than the dollar amount rather than each line item, Google could now sell advertising for say, MacWarehouse, that would show up on technology related queries by users who they know have made purchases at MacMall. It would be no different than checkout coupons at the grocery store. Anyone who has purchased baby food has probably received coupons at checkout for a competing vendor. If Google is able to see each line item, the information only becomes even more powerful. Looking at what amazon can do just with their knowledge of how their site is used, imagine what could be done where your purchasing habits were aggregated across a wide number of e-commerce sites.

My point of this post was not to raise a bunch of privacy concerns, however. I know that data collection is a part of life and I think it does far more good than harm. What I really began thinking about is the notion of personalized services, the outcome of collecting all of this data. What is the appropriate way to incorporate personalization into a Web Service? Does personalization impact the interface definition? The more common example is alternate implementation paths, which wouldn’t necessary imply a new interface. An example of this is the gold-platinum user. Perhaps their requests always get routed to the server with the least amount of load. Another example would be a flight reservation system. If the system knows that I always request window seats, a personalized service would always recommend a window seat when available if the request came from me. Other simple cases could simply be the inclusion/exclusion of particular operations. Outside of formating of values, I haven’t come up with a great example of where the interface would vary, but I’m sure they exist. It’s a difficult question though, because personalization is usually associated with something that’s destined for a user rather than something that is destined for another system. The one thing that is a definite must, however, is that identity must be on all service requests. There should be no such thing as an anonymous request. If not, you have no hope of personalization.

So, has anyone out there run across some case studies of personalization applied to SOA?

Joe McKendrick of ZDNet picked up on my so, uh, duh… blog entry regarding the new SOA 2.0 moniker. My previous post merely pointed to the petition to stop the madness. Something that is unfortunate in all of this is the actual reasoning behind the new moniker. Oracle and Gartner are trying to encourage the incorporation of events into SOA efforts. This, outside of the name, is actually a good thing. Bloggers like Brenda Michelson (eBizQ, elemental links) and Mike Herrick have posted on the importance of event driven architecture and its relation to SOA, as have I. Others out there clearly feel that EDA is a subset of SOA, and therefore there is no need to call it out. Personally, I think there is a risk that the need for events can get lost. A service is something that is available for the public good. It has to be requested. An event does not necessarily represent a request. It is merely a statement of something that has happened. What makes events so great is that anyone who is interested can choose to take action. The source of the event is not required to have any expectations of actions that will take place. It certainly can, but it doesn’t have to, unlike a service request. If we come back to the goals of SOA, a key one is agility. I don’t see how we can be agile without events. They bring exposure to happenings to a wider audience than the silo in which the action happened. That’s what it is all about. If we don’t break down the silos, we can’t be successful. Stop the madness. Ensure your architecture fully embraces services AND events. Just don’t call it SOA 2.0.

Brenda Michelson has posted a summary of current conversations between myself, Anil John, and Mark Griffin. My apologies for not posting this directly as a comment, but the response was getting long. She had four questions to continue the conversation that I’d like address as much as I’m able.

1. …understanding the business is critical in preparing an organization for SOA. But what else? As Mark asks, how can he ensure his organization is ready to deliver?

   My first comment refered to the importance of understanding what it takes to be an internal service provider. You can’t just build a service and forget about it. Outside of that, however, you need to have an understanding of the entire picture of SOA adoption. Ben Moreland of the Hartford gave a great presentation on their SOA Maturity Model. It’s a multi-dimensional effort. My dimensions would be (and they are very similar to what Ben presented):

   • Strategy: Bottom up, top down, etc.
   • Standards: What industry standards are you using? What internal standards are you creating?
   • Governance: How are you enforcing the standards? What oversight do you have in place (more on this later)
   • Capability: What is are the skills and capabilities of your staff? How are you training them?
   • Technology Infrastructure: Tools and technology for both development time and run time
   • Processes: What processes have you put in place to support all aspects of the adoption?
   • Architecture: What services have been created? What services do you plan on creating? Do you have references architectures, blueprints, and patterns to facilitate development?
   • Organization: How is the organization changing to support the effort? Do you have dedicated development teams?
2. And the other fork from Mark: “How do I get my IT organization more involved with the business to really understand it?”

   I recommend trying some user-centered design techniques. It’s been a long time since I’ve been able to practice them myself, but if you can find a way for your IT staff to do some field observation, they could learn a lot. Perhaps we need the business to sponsor a “Take your IT buddy to work” day. While I may be poking a little bit of fun, you’d be surprised what you could learn by just tagging along with a business worker for a day. Brenda, is there anything you can share from your own experiences or that of the Patricia Seybold Group?

3. What tools and/or methods are effective for top-down, bottom-up business and service modeling?

   I haven’t had the opportunity to dig into this personally. Clearly, existing modeling tools for software development projects work for the bottom-up case. For top-down, it’s all about business process modeling. I’ll leave this one for other people to offer suggestions.

4. How about that “elusive” governance? How do you sell Governance to IT and Business Leadership? Where do you get the money for people, process and tools? How do you convince people “Governance is good for you” rather than “Governance is a roadblock”?

   This is a tricky one. If your organization has some form of formal reviews, you’re already performing some governance, so it’s simply a matter of utilizing the existing gates to address service issues, such as reviewing the existing service library for possible services, determining where organizational ownership should lie, etc. If you don’t, then it’s time to start gathering some evidence to show the need. I would expect that sooner or later, a situation will arise that formal governance should have caught. The other way I would try to recommend governance is to first get some understanding on barriers to SOA, the biggest of which are the constraints placed by projects. If the project team stays constrained, odds are the effort will only yield results that are of value within those constraints. The only way to get around this is to give someone the responsibility to look outside of those constraints. Assigning the project staff to do this puts the project at risk. A better approach is to assign someone from outside the project to do this at the appropriate times. If you’re able to get people to understand that thinking outside of the box is a requirement for SOA, they may allow a pilot governance program to begin.

In a followup comment to the question on preparing for SOA, Mark Griffin asks whether it is possible to focus too much on the business, ignoring the IT deliverables. I think this is certainly a risk. While the failures were probably not due to an ignorance of technology, the business process re-engineering movement, noted by techniques such as Six Sigma, certainly left a lot of failed initiatives in its wake (at least according to books I’ve read, I have not personally been involved in such an effort). Likewise, I also believe that is possible to perform business process analysis and embrace business process technologies and completely miss all the benefits of SOA. As Anil John points out in his response, “Approaching SOA from both the Top-Down/Business Process perspective as well as the Bottom-Up/Service Factoring perspective allows for the identification of the re-usable aspects in a business process and to realize that re-usability using the service implementation technology of your choice.” This is well stated. The way to ensure that business process paralysis doesn’t happen is to embrace both a top-down approach and a bottom-up approach to your SOA and BPM adoption efforts. Strive to make the efforts meet in the middle. There is a challenge, still. Bottom-up efforts are more easily embraced because the starting point is well defined. Top-down efforts, are not so easily embraced. How high up do you go? I think this depends on your resources and the ability of those with business knowledge to contribute. You need to look broader than the bottom-up project at hand, but beginning at enterprise may be too far away to be practical. If the answer was easy, we’d all have done it by now.

Brenda Michelson, in her eBizQ blog, is encouraging a collaborative discussion around Business Driven Architecture. The first question posed by/to the blogosphere was on how to prepare your IT organization for Service Orientation.

MarkG’s stated that his “gut feeling says that IT shops that have a well established EAI practice or maybe have successfully embraced OO design will have the right mixed[sic] of governance and discipline to have a run at SOA.” On this, I have to disagree. I think a strong background in these technologies will assist in building service-oriented applications, but I don’t think it will go very far in yielding service-oriented architecture. The reason for this is that as long as all of the IT effort remains within the constraints of a single project, the organization will never understand it means to be a service provider. When a service provider and a service consumer are both working within a single project, the importance of these roles can be diminished, because there is close collaboration. Furthermore, the roles probably disappear when the project ends. What happens what the next consumer comes along? What happens when a project needs a service from a group that isn’t actively engaged on the project? How does the organization manage a service whose business logic spans multiple groups within the organization?

To me, the ability for an organization to succeed is going to be highly dependent on their ability to communicate, collaborate, and manage the service lifecycle, independent of whatever technologies are involved. I had the opportunity to comment about this in a recent ZapThink podcast. Please give it a listen and share your thoughts.

Thanks to Burton Group for putting on a very good conference in San Francisco this week, and more kudos to Anne Thomas Manes for putting together a great day of talks on SOA on Thursday.

This conference really demonstrated how building a network can make these events far more useful. Besides this blog, I participate in a Yahoo group on SOA as well as some less active user communities. It never fails that a few fellow participants show up at these conferences and the hallway conversations are quite valuable. At Catalyst, I had the opportunity to meet with Anil John from Johns Hopkins Applied Physics Lab, Shawn Furgason from Rockwell Collins, Ben Moreland from The Hartford, and Jeff Barr from Amazon, as well as some friends from the vendor community including Andrew Nash, Dave Hollander, and Miko Matsumura. I also met Brent Carlson from Logic Library for the first time.

All of you conference attendees that are practitioners, if your company policies allow it, I encourage you to get active and participate in the community! You can make your conference experiences even better by doing so.

James McGovern, as he so frequently does, encouraged a conversation on the evil enterprise architect. He makes a number of great points in this post.

1. “Many enterprises are getting it twisted by mistaking process for architecture…”
   First, since this is presented without the context, the message is that in many enterprises, the architect has fallen into a role of the gatekeeper. Rather than spending time on strategy, layers of abstraction, and modeling, they are consumed by tactical decisions for projects at hand. If you think about this, it really is a problem. How often does a building architect have to approve the detailed design and implementation decisions by the general contractor? Odds are, the architect is off designing the next building. Architecture establishes constraints, and it is the beginning of the design process. The problem is that is in IT solution development, these constraints exist too much in the architect’s head and not enough in something that is consumable by the general contractor on the project. As a result, the architect has to be more involved in the day to day project operations, and their role becomes more about the governance process than about strategic modeling. One additional item of note: processes and architecture do go together when it is about process modeling.
2. “What would happen if EAs started to think about creating new business value by modeling and ultimately simplifying the complexities of the business domain?”
   Life would be better! A barrier preventing this is that the role of Enterprise Architect is usually an IT role, not a business role. I wish it was the case that this wasn’t a barrier, as the efforts of everyone should be about the business. It shouldn’t matter what organization it comes from. There’s no shortage of articles written on how IT workers need to become more business aware. Likewise, there are some very tech-savvy business workers out there. In the perfect world, the Enterprise Business Architect could come from either the business or IT, and would have the full support of the enterprise in trying to improve the business.
3. “Maybe if us EAs started noodling the notion of enterprise service models that would be a good first step.”
   Noodle noodle. I am a proponent for an enterprise service blueprint, and I think we’re speaking to the same thing here.
4. “Business value can also be created by understanding the marketplace (bazaar) and even the social domain in which one plays in (aka community). What if we were to enable better ways for communities to communicate and interact with each other in a meaningful way? Would this enable new business opportunities?”
   I feel even more strongly about this. Unless we understand the cultures involved and the appropriate way to communicate and collaborate, we’ll never live up to our full potential. Sometimes we communicate poorly, but even more often, there is no communication at all. There are diamonds in the rough to be found, and only by continuing to improve how we communicate and collaborate, looking for new ways of getting things done can we continue to innovate and be more productive. A strange but accurate example of this is American Idol. The recording industry has been around a long, long time with set processes for finding new talent. There are many talented singers out there who simply have no exposure to that process. Along comes American Idol that challenges the way that singers are matched up with the recording industry, and a phenomenon is born. We must continue to search for ways to allow new ideas to get to the ears of people who need to hear them.

Ismael Ghalimi, on his IT|Redux blog recently posted that BPM 2.0 is Middle-Out. This was in response to another blog from Christopher Koch at CIO Blogs.

In Christopher’s article, he discussed that the business-side proponents from the historic business process re-engineering days now have technology on their side, BPM. Meanwhile, IT has SOA on their side. He concluded with a comment that BPM represented a top-down approach, while SOA represented a bottom-up approach.

Ismael picked up on that last comment to stress that BPM should not be a top-down approach, but rather, a middle-out approach where the process analyst is able to begin at the meeting point of IT and the business and work outword in both directions, one toward the business, the other toward the technology. He goes on to state that SOA and BPM are two sides of the same coin.

First off, it’s unfortunate that any controversy around SOA and BPM even exists, and I hope the analysts and columnists out there don’t try to fan the flames. Most SOA pundits I know completely understand the relationship between BPM and SOA, and how they should be inseparable. Any attempt to break them apart is a chicken and the egg discussion, and not worth the effort. Simply embrace both, and be done with it.

As for the whole top-down versus bottom-up discussion, here’s another case where the terms are used in so many different ways that it’s just making things confusing. Top-down versus bottom-up traditionally has to do with one thing: scope. Just because something may be driven out of the lines of business instead of IT doesn’t imply that it is top-down, and the same holds true in reverse. The middle-out discussion from Ismael has nothing to do with scope, either, it has to do with the business and IT operating as a team for a collaborative solution. David Linthicum discusses outside-in SOA with the increased number of externally hosted services available. Again, this has nothing to do with scope, it has to do with the physical location of the service processing. While Dave has good things to say, this does create confusion when an organization is simply trying to scope their effort.

If we agree that the fundamental concept is scope, the challenge is then choosing it appropriately so that strategic benefits can be achieved. The business side can easily have their focus on a particular problem of particular LOB that can lead to a bottom-up approach. Likewise, IT has a cross-cutting position that can allow it to take a broader view, seeing things from a top-down perspective, or vice versa. So how does an organization go about choosing the right scope? The key is understanding the business. What makes this difficult? In my opinion, it is projects. Why? Projects, as soon as they are defined, automatically limit the scope of the analysis. Trying to perform analysis that goes beyond the scope of the project is the worst nightmare for a project manager. From a bottom-up perspective, analysts need to try to get away with as much as they can to understand the business beyond the scope of the project at hand. A business process analysis approach can help do this, and can be justified in the name of creating a more usable, appropriate solution. This will help move us up a bit from the bottom. At the same time, organizations need to be performing analysis without any particular solution in mind. Akin to a top down approach, an organization can simply attempt to document business processes at a department or division level and wait for the results to determine what projects should be put in motion. This allows them to focus on opportunities for strategic improvement, rather than continue to put band aids on current pain points.

The gist of this long post is that BPM and SOA are inseparable. Likewise, any enterprise adoption will involve both bottom-up opportunities and top-down opportunities. By managing those efforts and ensuring that everything keeps going in the same direction, your chances for success will go up.

I recently posted on being an internal service provider. I’m happy to say that courtesy of Jason Bloomberg and Ron Schmelzer at ZapThink, you can now hear a lot more of my thoughts on the subject. Last week, we recorded a podcast entitled Taking a Product Management Approach to Services. You can hear quite a bit about the concept of product management that we practice at my day job, and how that experience is providing benefits as we embrace SOA.

I’d like to thank Jason and Ron for the opportunity, it was an enjoyable experience. James McGovern is always asking enterprise architects to blog, speak at conferences, etc., and I’d like to second that call. I don’t know if the ZapThink guys plan on making a series out of this, but personally, I’d love to see it- not just with me, but with a number of practicing enterprise architects.

The podcast-based interview provides an excellent forum for discussion and an opportunity to share knowledge with peers in a format that is far more convenient (and, as Jason & Ron point out, vendor free) than the typical industry conference. I have a long history with the ZapForums, beginning when they were done in a live format. Any of you who followed them know me as the regular listener who always had a question for the presenter. When they switched to a podcast format to reach a broader audience, Jason and Ron were kind enough to offer an opportunity to record one, and my employer was kind enough to give me permission to do so.

Please give the podcast a listen, and don’t hesitate to drop me a comment here or send me an email if you have further questions!

I was a bit annoyed when people suddenly stopped saying S-O-A and started saying so-ah, or as I like to point out, “So, uh…” That was only a pronunciation change. The worst that could come out of that would be kids in the National Spelling Bee asking, “Are there any alternate pronunciations?” (It was on in our corporate fitness center during my workout today…)

Well, if you haven’t heard, Gartner and Oracle have both starting using the term SOA 2.0. With some liberal pronunciation from a French descent, that now yields, “So, uh… duh!” That about sums it up. Duh! We don’t need “2.0”. Go sign this petition and stop the madness.