Todd Biske: Outside the Box

Archive for the ‘SOA’ Category

This is my last post from the summits (actually, I’m already at the airport). This morning, I participated in a panel discussion on EA and SOA as part of the EA Summit with Marty Colburn, Executive VP and CTO for FINRA; Maja Tibbling, Lead Enterprise Architect for Con-way; and John Williams, Enterprise Architect from QBE Regional Insurance. The panel was jointly moderated by Dr. Richard Soley of the OMG and SOA Consortium and Bruce Robertson of Gartner. It was another excellent session in my opinion. We all brought different perspectives on how we had approached SOA and EA, yet there was some apparent commonalities. Number one was the universal answer to what the most challenging things was with SOA adoption: culture change.

There were a large number of questions submitted, and unfortunately, we didn’t get to all of them. The conference director, Pascal Winckel (who did a great job by the way), has said he will try to get these posted onto the conference blog, and I will do my best to either answer them here on my blog or via comments on the Gartner blog. As always, if you have questions, feel free to send them to me here. I’d be happy to address them, and will keep all of the anonymous, if so desired.

I just finished my panel discussion with Mel Greer and Mike Kavis on measuring the value of SOA. I think we all had hoped that there would be more attendees, but hopefully those that chose to attend got something out of it. My main message was measure, measure, measure. I think it’s difficult to put a direct value on SOA adoption, that is, one where you can say the value was directly as a result of SOA efforts, but it’s not difficult to put a contributory value on SOA adoption. In other words, we need to measure the way IT is contributing to the success of the company as a whole, and as part of that, we can see some before and after measurements to see the impact of SOA and any other changes. The two things that I brought up in answering questions that I thought I’d share here are:

• Instrument your services now. Part of the problem with measuring things today is that we haven’t instrumented things in the past. These days, value is almost always expressed in relative terms, such as “relative to what we’re doing now.” If you’re not collecting metrics, you can’t say what “now” is, though. Once again, we’re at one of those unique opportunities where the door is open to do things differently. Put the instrumentation in now, before you have a portfolio of 100+ services that have no instrumentation.
• Measuring puts the spotlight on you, but will always enable you to answer questions better than before. A member of the audience asked the question, “What happens if your measurements show that you’re not achieving your goals?” This was a great question. Unfortunately, sometimes by the mere act of measuring things, people will immediately put the blame on you when things aren’t achieving the desired benefits, simply because you’re the one thing that can concretely demonstrate contribution (or lack thereof). My answer to this was two-fold. First, it was to try to make sure you have the backing metrics to allow proper root cause analysis. If you just focus on one metric, and nothing else, it makes root cause identification very difficult, and it puts the spotlight at the one area when you’re measuring. This puts strategic initiatives like SOA at risk, because people will think the whole thing is flawed, when in fact, the lack of results may have nothing at all to do with SOA adoption. Second, I talked about the appropriate spin to put on it, this being the political season in the US. When something doesn’t work out as planned, the way to spin the metrics is to show that we’re in a better spot to fix the problem because of the measurements than we would have been before.

The final thing I wanted to call out was a reference to a blog I posted yesterday at the request of Rob Eamon. Someone asked a question about how to get the stated goals from “the business” and the role of IT in contributing ways of measuring it. I called out that IT is part of the business, so there’s no reason that IT can’t contribute to the definition and appropriate ways to measure the business goals. Rather than viewing it as an “extraction” effort, it should be a joint effort with all members of the business, which includes IT.

If you attended the session, please feel free to post any comments or questions here. I hope it was valuable.

Presenter: Daniel Sholler

Dan is largely presenting results from some surveys that Gartner has done. Highlights:

1. Adoption is increasing, but so is number of organizations that are choosing to delay/do nothing
2. Nearly all organizations are at maturity level 1
3. Of the very few organizations that are above level 1, interest/usage in WOA/REST is increasing
4. More mature organizations are using services for B2B and multi-channel applications
5. Only 1/3 of organizations adopting SOA are using an ESB
6. Stage 2 maturity companies have nearly double the number of service consumers for the same number of services as Stage 1 maturity companies
7. “BPM is the ‘killer app’ for SOA”

My thoughts: Nothing really surprising here. I’m not at all surprised that we’re at a very early stage of maturity. The statement that the more mature organizations are pursuing B2B and multi-channel opportunities is an aberration, in my opinion. I think those are simply opportunities that some organizations have and other don’t, rather than being tied to the maturity of the organization. The bullet point that more mature organizations have twice the number of consumers was interesting to me. That one seems to make sense from a maturity standpoint. The BPM comment isn’t surprising at all, because I don’t think you can do a good job with BPM without having services.

I’m in a SAP session now. They’ve got their “End-to-End SOA Composition and Middleware Platform” picture up right now. It’s always nice when your vendor’s picture aligns with your own. Specifically, they have a separation between their Enterprise SOA Provisioning layer and their SOA Interoperability layer. Enterprise SOA Provisioning includes “Service and Event Enablement” and “Connectivity and Integration.” In SOA Interoperability, they have “Service Bus and SOA Management.” Thanks to the confusion between the ESB space and EAI space, these two layers are frequently combined, and I think they should be separate. The SOA Interoperability layer should be about mediating across a set of standards that the enterprise has adopted, which the enablement and integration layer is about hooking non-standard things into it. Push those pieces as close to the endpoints as possible, and put the stuff that’s required on all standards-based service messages in the middle. Unfortunately, they’ve now put up a slide on SAP NetWeaver Process Integration 7.1 and are positioning it to cover Service Bus, Service Integration, and SOA Management. So, conceptually they get it, but in terms of the product mapping, there could be some challenges if you don’t deploy it properly. If you separate out one PI environment for SOA Interoperability, and a second environment for Enablement and Integration, a lot of the potential risks can be mitigated.

Presenter: Benoit Lheureux

This was a decent overview of a whole bunch of things including composite applications, *-as-a-Service (software, platform, etc.). I would have preferred it if this presentation had taken more of an advisory, rather than informing, approach. There has to be a large number of enterprises represented here who have SAP, Oracle, or something else in their environment. Rather than going into depth on how to incorporate (e.g. best practices) these packaged applications into an enterprise’s SOA efforts (it did cover it, just at a light level), it went for breadth and spent a lot of time discussing packaged vendors and SaaS providers and their approach to SOA.

Presenter: Jeff Hiatt, Prosci

Jeff isn’t with Gartner, so this session should be different. It’s already started well his use of these green and red cards we all have. He’s asked us a few questions and asked us to raise either the green or red cards. It’s made it very easy to see answers instead of the usual hand-raising approach.

His first statement on his slides is: “The speed of technology deployment will not be gated by IT innovation, but rather by the ability to manage the people side of technology changes.” Absolutely!

He just walked us through an exercise where we wrote down a project name, its purpose (why are we changing), the particulars of it (what we are changing), and the people that will need to change how they work (who will be changing). He pointed out that most technology professionals don’t consider the last column and really struggle with answering it, but yet not dealing with it can stymie the entire effort.

We just did another example where he asked the audience how many people have managing the people side of change as part of their job responsibilities, and there were about 10 people who said yes. That’s a big problem if this can be the biggest challenge in being successful.

We’re now walking through some best practices for managing change. The first deals with sponsorship. Jeff called out how sponsors need to be actively engaging throughout the lifetime of the project, building a coalition of support for the change. He especially emphasized middle management, as their research has always shown that middle management is the most difficult group to change.

Item two was having a structured approach the managing the change associated with the project. I don’t know that I’ve ever been on a project that had this, although, one challenge we have in IT is actually having visibility into that. If the change required is in the business side, often times that is invisible to IT. That, in and of itself, is a problem.

The third item is communications. Of course, face-to-face communication is important. Another important this is who delivers the message. The preferred sender of change messages is one of two people. For business messages, it’s the CEO or President. For personal messages, it’s the employee’s direct supervisor.

The fourth and fifth items were dedicated resources for change management and employee participation. We were all scoring ourselves as we went through this, and in the end, we used the red card/green card “visual vote” and it was very clear that about 95% of the people in the room were at risk for having poor change management. Definitely a very clear message, the real question in my mind is how to get IT visibility into the change that our solutions will introduce into the business. This strikes a chord with me, since I’m a big proponent on involving end users from my background in usability. Good talk!

Presenter: Daniel Sholler

It’s Tuesday morning, and I’m attending this one over breakfast. He’s just made an interesting comment regarding companies, using the insurance industry as an example. He stated that while most insurance company provide the same services, they differentiate based on how they organize. I was hoping he’d take this further and talk about how organization impacts SOA adoption, but no luck.

Another comment he made is that Gartner sees a correlation between companies that succeed with SOA and companies that have mature identity management practices. If identity can’t flow through all of your service interactions, you’re going to run into problems. I agree with that.

On to standards. He has another slide up that shows the different types of relationships an organization may have. At the bottom, a completely internal interaction relies on a private subset of information and process models. In the middle, a company talking to a partner has a closed agreement that defines them. At the top, a company interacting with a “cloud” service has an open agreement. Anyone interacting with the cloud can see the information and process models available. He’s then gone on to show how their is a spectrum of standards that one must be concerned with. Once again, no arguments here.

Presenter: Anthony Bradley

Anthony’s going to present Gartner’s new framework for building SOA business cases. He immediately began by stating that you can’t build a general business case for SOA. Rather, the point is to build an SOA business case for a particular business need. I can tell it’s the end of the day, as my attention span is dwindling quickly. This framework presentation is having the same impact on me as when I was first introduced to RUP. It appears to have a level of detail that makes it difficult to digest. The other thing that hasn’t been immediately apparent to me is why this isn’t a framework for building IT project business cases in general, rather than just SOA business cases. I’ll have to dig into the notes on this one, but right now, I’m a bit skeptical.

Presenter: Matt Hotle

“Governance is the key to predictable results” is the title of his first slide. At first glance, I disagreed with this statement, but as he explained it, he emphasized the use of policies and how they guide decision making. That I agree with. I don’t know if I’m comfortable going so far as to saying it’s the key to predictable results. I think it’s the term “predictable” that’s causing my discomfort. As I’ve said before, governance is about achieving a desired behavior, which is a slightly different view than predictable results. When I hear “desired behavior,” I don’t think of standard processes, when I hear “predictable results,” I do. Perhaps I’m nitpicking since I’m somewhat passionate about this space.

BTW, 92 minutes into the Steve Jobs’ keynote, iPhone 3G has just been announced. Are they selling them anywhere in the Orlando World Center Marriott? No? Rats. Now back to governance.

The slide he’s showing now has one very good nugget. He states, “SOA Governance needs… a funding model to maintain services as assets (service portfolio management/chargeback).” I’ve always felt that if an organization wants to do services the right way (see Service Lifecycle Management), it would inevitably wind up challenging the typical project-based funding model in most IT shops. Matt is now talking about the term “application” and while he didn’t go as far as I have in the past (see The End of the Application), he did make it clear that the notion of “application” needs to change. He just hit another key point with me! He said that what he’s outlining is “product management” and most IT shops don’t have a clue how to do product management. Boy does that sound very familiar (see this, this, this, this, and listen to this).

Roy Schulte is delivering the opening keynote. Right now, he’s presenting a good slide on integrating applications from outside of your domain and emphasizing the role of metadata and policies in formalizing the agreement between service consumers and service providers, all because of the need to build applications that cross the boundaries of different domains, whether inside the enterprise or outside the enterprise. I agree!

Roy’s now presenting what he feels will be the major improvements in business computing over the next 5 years. They are:

1. SOA, EDA, REST, BPM, and SaaS will improve the long-term business agility while reducing the life cycle cost of application systems.
2. BAM is IT’s biggest near-term opportunity to shine.
3. End users will have more direct control over the applications they use, and IT solutions will be more customized.
4. IT systems will become better able to handle data in the form of documents.
5. End users will participate more actively in information capture, information sharing and collaboration.

Raf Cammarano posted a great response to my last two blogs (here and here) on his blog. The title of his entry says it all: “No More Groups, Committees, Centres or Offices.” He asks the question whether a center of excellence or competency is even necessary at all. The risks he calls out are (with quotes from his blog):

1. Staffing: “Who is going to look after the other things when the best architects are poached by another group?”
2. Overlapping Responsibilities: “There will be huge overlap between the functions of the new group and the existing EA Group.”
3. Cross-functional teams are usually temporary: “The simple reason cross-functional groups are temporary is because the best people are reluctant to get off their career path within the business and move into a ‘special project’ permanently. SOA is not a ‘project’ and it’s certainly not ‘short term’.”

His recommendation is simple: “If your EA Group can’t deliver on everything that a Centre of Excellence would be expected to – then fix your EA Group!”

I really enjoyed this post as Raf raises many good comments that you should think about before you decide to go down the path. My posts were intended to offer some advice once you’ve made that decision, but it’s absolutely critical that you first look at whether it’s even needed. Addressing Raf’s concerns one at a time, let’s start with staffing. He’s absolutely right that staffing is a concern, as most groups aren’t willing to let someone go and live within some other virtual organization that controls their day to day activities. I’ve seen an organization where the top people, the ones who should have been driving the effort, specifically weren’t chosen due to the “hero” culture that existed and the dependency the organizations had created on them. I’d be willing to bet that these organizations may struggle to establish an EA team for the same reason. The successful COEs and Competency Centers I’ve seen had sponsorship from a very high level, typically the CIO or one management level beneath them. This helps prevent people from hanging on to resources that should be contributed at an enterprise level.

As for overlapping responsibilities, again this is certainly a risk. I’ve seen this resolved by actually assigning staff from EA to the COE, as well as having sponsorship from the Chief Architect. One thing to note, though. I think any COE or CC will have overlapping responsibilities with one or more organizations. It’s important that the COE is seen as an authority (just as EA must be seen as an authority) to help mediate when it occurs. The one thing you do want to avoid is complete overlap of responsibilities with another team. A COE or CC makes sense when there may be partial overlap and focus on the effort is needed. When there’s complete overlap, then you should have been looking at the team being overlapped to begin with, whether it’s EA or any other organization.

Finally, he points out that cross-functional groups are temporary. This was actually the original theme of my posts, so I don’t view this as a concern, but rather an option. What is bad is when a group that was supposed to be temporary lingers on indefinitely.

Anyways, thanks to Raf for the great comments. If you review my posts as part of your decision making process on a COE or CC, I suggest you review Raf’s as well.

I should know better than to blog late at night. I will never be classified as a night person. Anyway, in reading back over my post yesterday on Centers of Excellence or Competency Centers, I never quite finished my train of thought, but a post from the SOA Consortium blogs by Brenda Michelson refreshed my memory. This post recaps a podcast from their March meeting that discussed the topic of SOA Centers of Excellence. In the post, she called out that the panelists articulated the skills required to operate a SOA Center, which included:

• Project/Portfolio Management
• Service Design
• Business Knowledge
• Technical Aptitude
• Communication
• Teaching
• Governance

This list reminded me of a different view on COEs and Competency Centers. A challenge with SOA adoption is leadership. Who drives the organization’s adoption of SOA? If you’re like me, and don’t view SOA as just a technical thing, there’s no easy answer to the question. While enterprise architecture has the appropriate scope of visibility and influence on the technical side, they’re not the best group for handling organizational decisions. From the organizational side, there may an IT leadership group or committee that could handle it, but what about the technical aspects? This is where a cross-functional group may make a lot of sense and could be quite long lived. I know I’ve always thought of SOA as at least a 5 year effort, and looking back now from 5 years after I first said that in an organization, 5 years was clearly too optimistic.

Even given this long-term commitment, I still think the people running the SOA Center should always plan on having a time-limited lifecycle. SOA should become part of the normal way IT operates, not something that requires a special group to manage. While a cross-functional group will be required at the beginning, at some point, individual managers and technical leaders must take responsibility for their parts in contributing to the overall goals of SOA. It may not occur until sufficient organizational change (restructuring, not necessarily people) has taken place, but the goal of the program must be to make the behaviors associated with SOA normal practice, rather than something that must be explicitly enforced because it’s still outside of the norm.

The east coast Gartner AADI and EA Summits (that’s Application Architecture, Development, and Integration and Enterprise Architecture) are nearly upon us, and thanks to the SOA Consortium and Gartner, I’ll be part of two end user panels again. In the AADI Summit, I’ll be speaking with Mike Kavis and Melvin Greer on “Measuring the Value of SOA.” I think I’ll bring an interesting perspective to this. That session is at 10:45 AM on Wednesday, near the end of the AADI but right before the beginning of the EA Summit. At the EA Summit, I’ll be part of a panel with John Williams, Maja Tibbling, and Marty Colburn in a session titled “SOA and EA: Lessons Learned from the Trenches.” That one is at 8:30 AM on Friday, so stop by the coffee shop on your way down to conference center and pick up a double latte. I’ll be at both events (and blogging) for the duration of them, so stop by and introduce yourself.

Surekha Durvasula had a very good post entitled ‘Why you need a stated “service versioning policy.”‘ In it, she presented 6 different scenarios where multiple versions of services may be required. If you don’t think you’ll need to deal with versioning, perhaps you should review these scenarios and determine how you’ll handle them when the need arises.

In a blog entry last week and his podcast for this week, David Linthicum lamented the fact that many technology vendors are too focused on integration and not enough on architecture. My opinion on this is that the problem lies first with enterprises, and not with technology vendors.

In order to first explain this, I need to split the technology product space into two large groups. First, there are products that are pure infrastructure. They are platforms on which someone else builds solutions. This is the familiar space of database platforms, application servers, network appliances, EAI platforms, ESBs, MOM servers, etc. For products in this space, I have absolutely no problem with the vendors providing products that are focused on making integration easier. Does this enable enterprises to build up layers of “glue” in the middle? Absolutely, but at the same time, the enterprise had to have a need (whether perceived or real) to make their integration efforts easier.

The second group of technology products are the actual business solution providers, whether it’s a big suite from SAP or Oracle, web-based solutions like Workday and Salesforce.com, or anything in between. These vendors absolutely should be focused on architecture first. At the same time, I don’t think many of these products are being marketed and sold on their integration benefits, they’re being sold on their business capabilities.

So, what’s the problem then? The problem comes when the enterprise IT staff involved with technology identification and selection is too focused on integration, rather than architecture. Almost always, when I hear an enterprise talk about integration, it’s a just in time effort. Someone is building some new system and as part of the design of that system, they decide they need to talk to some other system. No thought of this need occurred in advance from either side of the integration effort. In putting together the solution, the focus is simply on the minimal amount of work to put the glue in the middle. As long as this trend continues, the infrastructure vendors are going to continue to market their products to this space. While it’s a noble quest to try to educate and market at the same time, it’s a risky strategy to present using a different mental model than your target audience.

The change that needs to occur is that integration needs to be a primary principle that is thought about at the time a system is placed into production. Normal behavior is to build a solution for my stakeholders and my users, and not think about anything else. In past posts (here, here), I’ve talked about three simple questions that all projects should start thinking about. One of those questions is “What services does your solution use / expose?” How many projects actually identifying anything other than just what their front end consumes? Does anyone see this as a problem? Let’s come back to the infrastructure vendors. They actually do need to think about architecture and services, but in a different space- management. I’ve railed on this in the past. How many vendors expose all of the capabilities in their user-facing management console through one or more service interfaces? If I want to embrace IT Systems Automation, how on earth am I going to do this what what these vendors give me? I’m not. I’m going to have to leverage management adapters in more automation environment. Does this sound familiar? It sure sounds like EAI to me. The best way I see to address this is think about integration in advance. Don’t think about it at the time someone comes and says, “I need to talk your system,” think about it at the time you build your solution and ask the question, “How will other systems need to interact with this.” Yes, this is a bit of predicting the future, and we’ll probably expose things that no one ever uses, but I think an enterprise will be in a better state if they try to anticipate in advance, thinking about architecture, rather that continue with today’s approach of integrate on demand.