Archive for the ‘Business’ Category

More from the Technology Garden

I previously posted some thoughts on the new book from the Neils at MacehiterWard-Dutton along with Jon Collins and Dale Vile from Freeform Dynamics called “The Technology Garden: Cultivating Sustainable IT-Business Alignment.” I finally got a chance to pick it up again, and I thoroughly recommend chapter 8, “Foster relationship with key IT suppliers” for anyone who has an involvement in vendor decisions. Working with vendors is an art, and it’s not just the department head who needs to do it. They give some practical guidance on how to determine who your strategic vendors are, and who the vendors are that you simply deal with on a transaction by transaction basis. In addition to this, they also give prescriptive guidance on working with them, and the art of the win-win solution.

In addition to being of value to vendor relations, anyone adopting SOA should also understand this chapter. Why? Because if you’re a service provider, a lot of the same conflicting pressures occur between consumer and a provider. Strive for the win-win situation, and you’ll be better off. It’s not easy to do, especially when you have multiple consumers each with their own priorities.

Will your culture allow an impact player?

Jordan Haberfield of Excel Partner recently posted a blog titled “Enterprise Architects as ‘Impact Players'”. I’ve enjoyed Jordan’s blog as it discusses EA from a different perspective, one of talent and corporate culture, rather than the technical aspects. I’ve always found the human and social aspects of things very interesting.

Anyway, he provides an excerpt from a book he read called “Don’t Send a Resume: And Other Contrarian Rules To Help Land A Great Job” by Jeffery Fox which introduces the role of the impact player. Here’s the quote:

“There is always a job in a good organization for an impact player. An impact player is someone who can quickly improve the economics of a company. An impact player is someone who can bring in customers, energize the sales force, restructure an under-performing department, speed up the innovation process, solve the late shipment problem, or physically move the manufacturing facility to a lower cost area. An impact player also is someone who will do the necessary but noxious tasks no one else wants to do. An impact player is someone who will get their hands dirty, pick up a shovel and start shoveling, open the store early and close late, deliver product on their way home, deal tirelessly with irate customers and make a service call on Christmas Eve. Good executives in good companies want to hire impact players.”

Jordan goes on to state that “Enterprise Architects are in a position to become that impact player and make a significant difference.” It’s probably better stated that Enterprise Architects should be in a position to do this. Whether they are or not is highly dependent on the corporate culture.

I’ve spoken with a number of colleagues in the St. Louis area, and it’s my understanding that many of the organizations here where I reside don’t even have a formal EA group. Why is this important? It’s important because I believe that an impact player often has to transcend boundaries and operate outside of the constraints that a particular job description may imply. If an organization doesn’t have an Enterprise Architecture discipline, someone needs to go outside of the box of their current job description and start doing EA. If the corporate culture is resistant to people operating outside of their formal job description, that impact player is going to need some very thick skin.

A great example is from two years ago when Jason and Ron at ZapThink emphasized the need for the SOA Champion to guide an organization through SOA adoption. SOA is not about buying an ESB, Registry/Repository, or any other tool. For the bulk of companies that comprise the “status quo” of Service Averse Architecture, it’s about a fundamental change to the way IT solutions are delivered which can cover organizational change, process change, and technology change. What organization has a formal role established for this position? Probably not many. It requires someone to be an impact player, think outside the box, transcend boundaries, and pave the path for the new way of doing things.

Some companies encourage individuals to think outside of the box and outside of their formally stated responsibilities, and it’s probably one that should be added to the litmus test for a company likely to be successful with innovation and strategic initiatives. After all, the degree to which a company does this is a matter of trust. Unfortunately, it’s far easier to break down that trust that it is to build it up. For those of you dealing with that, follow this link to another excellent book that I’ve read.

In summary, the original quote by Dr. Fox states that “There is always a job in a good organization for an impact player.” The key part of this is “good organization.” If you are exhibiting the qualities of an impact player, but you’re struggling to be successful, take a look at the organization’s culture and see whether it is a “good organization” or not. If you’re looking for a good organization, you may need to look for the foot-in-the-door opportunity, because often times, it takes an outsider to come in and recognize the areas for potential impact, so you’re not going to find it on Monster or Dice.

Are you in it for the business, or for the technology?

James McGovern had an interesting post recently entitled “Are Business Applications Boring?” It reminded me of some of my own experiences, both as a supervisor and as an individual. A few years ago, a group that I oversaw was very focused on Java middleware technologies. .NET was gaining in prominence at that time, and it was clear to me that the team would need to gain Microsoft experience, and it was entirely likely that the majority of our work in our future would be on the .NET platform. I told the team that they needed to determine what was more important to them: writing successful Java solutions or writing successful business solutions. In addition, I asked myself that same question. To me, I was more interested in seeing the organization and the business be successful than I was about writing Java code or C# code. For others, they chose to part ways with the company as the amount of Java work reduced. There’s absolutely nothing wrong with that, although, I do think there’s more long term risk for a developer in going that path. Why? It’s far easier to find someone who can write code than to find someone who understands the business and the culture.

Interestingly, I left the enterprise world about 9 months ago and joined the consulting ranks. That being said, if you’ve followed my blog, you’ll know that I don’t view SOA as a technology initiative. Proper application of technology in support of business needs is far more of a business issue than it is a technology issue, and that’s what interests me. My view on SOA consulting is that it needs to be focused on business consulting more so than technology consulting. This subject came up in a recent conversation with Dana Gardner and his analyst gang that will be published soon.

The short of this is that it is difficult for enterprise IT practitioners to hold on to top technical talent unless those individuals are interested in the business. If I were to go back to school today, I would pursue an MBA, not additional technology education. If individuals are solely focused on the technology, they are unlikely to get long term satisfaction from a 30-plus year career at one organization. Unfortunately, I haven’t seen very many developers who are passionate about understanding the business. I can’t remember the last time that I interviewed someone and had them ask me some serious questions about the business to see whether it would be a good fit, when you’d think that would be one of the most important factors.

In my mind, the writing is on the wall. If you’re in the early stages of your career and want to put yourself on a path for long term growth, you’ll need to build up deeper and deeper knowledge of the domains where you apply technology. If you just want to maintain a status quo, you can become a developer, however, I suspect that your salary will remain part of the status quo, as well.

Horizontal and Vertical Thinking, part 2

John Wu commented on my horizontal and vertical thinking post earlier in the week, and I felt it warranted a followup post. He stated:

Enterprise Architecture is a horizontal thinking while application development is a vertical thinking.

While I understand where John was coming from, I think that this approach is only appropriate at the very early stages of an EA practice. The first problem that an organization may face is that no one is thinking horizontally. This may go all the way down to the infrastructure level. Projects are always structured as a top-to-bottom vertical solution. While there may be individuals that are calling out some horizontal needs, unless the organization formally makes it someone’s responsibility to be thinking that way, it will have difficulty gaining traction.

Unfortunately, simply creating an EA organization that thinks horizontally and still letting the project efforts think vertically is not going to fix the problem. If anything, it will introduce tension in the organization, with developers claiming EA is an ivory tower and EA claiming that developers are a bunch of rogues that are doing whatever they want in the name of the project schedule.

If we characterize where the organization needs to go, it’s where both EA and the development organization are thinking both vertically and horizontally. This does come back to governance. Governance is about decision making principles to elicit the desired behavior. The governance policies should help an organization decide what things are horizontal, what things are vertical, and then assign people to work on those efforts within those architectural boundaries. Right now, many organizations are letting project definitions establish architectural boundaries rather than having architectural boundaries first, and then projects within those boundaries. Project boundaries are artificial, and end when the project ends. Architectural boundaries, while they may change over time, should not be tied to the lifecycle of a project.

So, EA should be concerned with both the vertical and the horizontal nature of IT solutions. Based upon the corporate objectives, they should know where it is appropriate to leverage existing, horizontal solutions and where it is appropriate to cede more control (although maintaining architectural consistency) to a vertical domain. Two systems that have some redundant capabilities but are architecturally consistent at least create the potential for a consolidation at some later point in time, when the corporate objectives and policies change. In order to do this, the project staff must also be aware of both the vertical and horizontal nature of IT solutions.

The Pace of Change in the IT/Business Relationship

I’m currently reading The Technology Garden: Cultivating Sustainable IT-Business Alignment by the Neils from Macehiter Ward-Dutton along with Jon Collins and Dale Vile of Freeform Dynamics. In the spirit of full disclosure, the publicist sent me a free advance copy of the book, as Amazon reports its availability as June 11th. I’m about halfway through it, and it’s been a pleasant read. Chapters four and five have particularly caught my attention. They are titled, “Create a common language” and “Establish a peer relationship between business and IT.” The common language chapter puts the onus on IT to learn the language of the business. While they also state that no competent business executive should be technology-ignorant (my words, not theirs), the bulk of the burden is on the technology staff. In the next chapter, it begins with a discussion on how many IT groups play a supplier role, and how that simply isn’t good enough these days. While service delivery and management is very important for building trust, it’s not sufficient. They state:

Suppliers, by definition, do what they’re told. The customer is always right! The parameters of service delivery are defined by the ‘customer,’ and thereafter the supplier delivers, in response to requests, in the context of those parameters (you can think of these as ‘contracts’ and ‘service-level agreements’).

When I read this, it occurred to me that as an industry, we really haven’t made much progress on the whole concept of IT and business as peers. I’ve mentioned previously that in my early days, I did a lot of work on user interface technologies, and had a strong interest in human-computer interaction during college. My first introduction to user-centered design techniques and viewing the end user as a partner in the process was in the summer of 1993. That was 14 years ago, and yet I’d have to say that in general, IT still operates in a supplier role, with things thrown back and forth over the business/IT wall. I really liked the emphasis on communication in Chapter 4 of the book. If the continued prevalence of IT as a supplier mentality is due to a fundamental lack of trust, the only thing that will eventually break it down is communication. I’ve certainly been guilty of falling into the typical technologist mode of communicating: email. As they call out, it’s time to starting getting out of our chairs, out of our comfort zones, and start communicating. If you don’t know who to begin your conversations with, seek someone out that can help you with that.

I had the experience of participating in an exercise directed by a CIO where we were split into groups of 8 people, and then furthered subdivided into two groups of 4 seated at separate tables. Each table had a task to accomplish as outlined on a piece of paper. All tasks were identical, and each set of 8 people had identical equipment at their table to complete the task. The goal of the task was to ensure that each sub-group of 4 built identical solutions. If you’ve seen Apollo 13, this whole thing was prefaced by a video clip from the movie where the engineers at Mission Control dump a box full of stuff on the table and have to figure out a way to build a carbon dioxide scrubber out of it. They then have to get the Apollo 13 astronauts to do the same. The interesting thing about this task was that the instructions were not very limiting. For example, there was nothing that said one group of four couldn’t get up and go sit with the other four and complete the whole thing together. The point of the exercise was that we set many artificial boundaries in our work based on past experiences, culture, etc. In fact, there are probably more artificial boundaries than real boundaries. Does your company have a stated policy that you can’t go and talk to an end user on the business side? If they don’t, there’s nothing preventing you from doing that. If we’re going to begin building trust back up in the IT/Business relationship, it is time to step outside of the box and start communicating as peers. Let’s not wait another 14 years to start making a change.

Horizontal and Vertical Thinking

I’ve been meaning to post on this subject for some time, so it’s good that I got to the airport a little earlier than normal today. There’s nothing like blogging at 5:30 in the morning.

As I mentioned in my last entry, I just finished listening to a podcast from IT Conversations on the drive to the airport which was a discussion on user experience with Irene Au, Director of User Experience for Google. One of the questions she took from the audience dealt with the notion of having a centralized group for User Experience, or whether it should be a decentralized activity. This question is one that frequently comes up in SOA discussions, as well. Should you have a centralized service development, or should your efforts be decentralized? There’s no right or wrong answer to this question, however, it’s certainly true that your choices can impact your success. In the podcast, Irene discussed the matrixed approach at Yahoo, and how everything would up being funded by business units. This made it difficult to do activities for the greater good, such as style guides, etc. The business unit wanted to maximize their investment and have those resources focused on their activities, not someone else’s. Putting this same topic in the context of SOA, this would be the same as having user-facing application teams developing services. The challenge is that the business unit wants that user-facing application, and they want it yesterday. How do we create services that aren’t solely of value to just that application. At the opposite extreme, things can be centralized. Irene discussed the culture of open office hours at Google, and how she’ll have a line of people outside her office with their user experience questions in hand. While this may allow her to maintain a greater level of consistency, resource management can be a big challenge, as you are being pulled in multiple directions. Again, putting this in the SOA context, the risk is that in the quest for the perfect enterprise service, you can put individual project schedules at risk as they wait for the service they are dependent on. These are both extreme positions, and seldom is an organization at one extreme or the other, but usually somewhere in the middle.

HorizVert.pngIn trying to tackle this problem, it’s useful to think of things as either horizontal or vertical. Horizontal concepts are ones where breadth is the more important concern. For example, infrastructure is most frequently presented as a horizontal concern. I can take a four CPU server and run just about anything I’d like on it these days, meaning it provides broad coverage across a variety of functional domains. A term frequently used these days is commodity hardware, and the notion of commoditization is a characteristic of horizontal domains. When breadth becomes more important that depth, there’s usually not many opportunities for innovation. Largely, activities become more focused on reducing the cost by leveraging economies of scale. Commoditization and standardization go hand in hand, as it’s difficult to classify something as a commodity that doesn’t meet some standard criteria. In the business world, these horizontal areas are also ones that are frequently outsourced, as all companies typically do it the same way meaning there is little room for competitive differentiation.

Vertical concepts are ones where depth is the more important concern. In contrast to the commoditization associated with horizontal concerns, vertical items are ones where innovation can occur and where companies can set themselves apart from their competitors. User experience is still an area where significant differentiation can occur, so most user-facing applications fall into this category. Business knowledge, customer experience (preferably at a partnership level to have them involved in the process), are keys at this level.

By nature, vertical and horizontal concerns are orthogonal and can create tension. I have a friend who works as a user experience consultant and he once asked me about how to balance the concerns that may come from a user experience focus, clearly rooted in the vertical domains with the concerns of SOA, which are arguably focused on more horizontal concerns. There’s no easy answer to this. Just as the business must make decisions over time on where to commoditize and where to specialize, the same holds true for IT. Apple is a great example to look at, as their decision to not commoditize in their early days clearly resulted in them being relegated to niche (but still relevant) status in computer sales. Those same principles, however, to remain more vertically-focused with tight top-to-bottom controls have now resulted in their successes with their computers, iTunes, Apple TV, the iPod, and the forthcoming iPhone. There are a number of ways to be successful, although far fewer ways than there are to be unsuccessful.

When trying to slice up your functional domains into domains of services, you must certainly align it with the business goals. If there is an area of the business where they are trying to create competitive differentiation, this is probably not the best area to look for services that will have broad enterprise reuse, although it is very dependent on whether technology plays a direct role in that differentiation or an indirect role, such as whether the business to consumer interaction is solely through a website, or if it is through a company representative (e.g. a financial advisor). These areas that are closest to the end user are likely to require some degree of verticality to allow for tighter controls and differentiation. That’s not to say they own the entire solution, top to bottom, however, which would be a monolith.

As we go deeper into the stack, you should look for areas where commoditization and standardization outweighs the benefits of customization. It may begin at a domain level, such as integration across a suite of applications for a single business unit, with each successive level increasing the breadth of coverage. There is no point where the vertical solutions stop, and everything beneath it has enterprise breadth. Rather, it is a continuum of decreasing emphasis on depth and increasing emphasis on breadth. A Internet company may try to differentiate themselves in their end-user facing systems that the users interact with, allowing a large degree of autonomy for each product line. The supporting services behind those user interfaces will increase in the breadth of their scope, but still may require some degree of specialization, such as having to deal with a particular region of a country or even the world for global organizations. We then bleed into the area of “applistructure” and solutions that fall more into the support arena. A CRM system will have close ties to the end-user facing sales portal. The breadth of CRM coverage may need to span multiple lines of business, unlike the sales portal, where specialization could occur. Going deeper, we have applications that may have no ties to the end-user facing systems, but are still necessary to run a business, such as Human Resources. Interestingly, if you’re following my logic you may be thinking that these things should all be outsourced, but the truth is that many of these areas are still far from being commoditized. That’s because they involve user facing components, which brings us back to those vertical domains where customization can add value. An organization that outsources the technology side of HR, but doesn’t have an associated reduction in HR staff may have a potential conflict when they want to have specialized HR processes, but are dealing with commodity interfaces and systems. Put simply, you can’t have it both ways.

The trend continues on down the stack to the infrastructure and the world of the individual developer. If you’re truly wanting to adopt SOA from top to bottom, there should be a high degree of commoditization and standardization at this level. Organizations where solutions are still built top-to-bottom, with customized hardware platforms, source code management, programming languages, etc. are going to struggle with SOA, because their culture is vertically-oriented to an extreme.

While the speed of change, business decisions on what things are core competencies and what things are not do not change overnight. Taking an organization where each product group had its own staff (vertically-oriented) and switching it to a centralized sales organization (horizontally-oriented) is a significant cultural change, and often doesn’t go smoothly. You only need to look at the number of mergers and acquisitions that have been deemed successful (less than 50%) to understand the difficulty. Switching from vertically-focused IT solutions to horizontally-focused IT solutions is just as difficult, if not more difficult. Humans are significantly more adaptable than technology solutions, which at the core, are binary, yes/no environments. The important thing is to recognize when misalignment is occurring and take action to fix it. That’s all about governance. If users are trying to apply significant customization to a technology area that has been deemed as a commodity by the business, push back needs to occur to emphasis that the greater good takes precedence over individual needs. If IT is taking far too long to deliver a solution in an area where time to market and competitive differentiation is critical, remove the barriers and give that group more control over the solution, at the expense of broader applicability. If you don’t know what your priorities and principles are, however, for each domain, you’ll end up in and endless sequence of meetings that are rooted in opinions, rather than documented principles and behaviors desired by the organization.

User Experience Podcast

I just listened to another great podcast from IT Conversations. This one is from the Adaptive Path series, and is a chat with Irene Au, the Director of User Experience at Google. Irene’s also a fellow alumnus of the University of Illinois (go Illini). User experience has always been a passion of mine, and it was interesting to hear what Irene’s done in her career at both Yahoo and now Google. The discussion was not so much about User Experience per se, but the way her and her teams have been utilized. If you’re interested in a little bit of insight into Google (the “testing on the toilet” part was great), I encourage you to give it a listen.

Barriers to SOA Adoption

The latest ZapFlash from ZapThink discussed what the real barrier to SOA Adoption is, and Ron points directly at IT as the source. He states:

What ZapThink is finding is that the primary barriers to SOA adoption do not come from business management … but rather from within the IT organization … too many people in the IT organization conceive SOA as a technology concept only, and as such think of SOA as just a set of technologies and infrastructure for exposing, securing, running, and managing Services.

As always, Ron walks the line of controversy with this entry. In reading the article, there’s certainly not much you can argue about as far as some generalizations of IT go. I have seen organizations that are clearly burying SOA within IT, thinking of it as just another application development technology, just as Ron describes it. On some recent work, I recently had created a slide that showed a picture of a bunch of monolithic applications and then breaking apart those monolithic into groups of services. Some may think that this is doing SOA. I’d argue that if that’s the only thing that changes, you’re probably not. In most organizations, there does need to be some fundamental changes in the way IT operates. That being said, what causes that behavior in the first place? Ron made one statement in the above quote, which I intentionally left out at first. Here’s the full text:

What ZapThink is finding is that the primary barriers to SOA adoption do not come from business management, which by and large realize the benefits of an agile, reusable, and loosely coupled architecture (even if they don’t call it that), but rather from within the IT organization …

The italicized text is what really surprised me. Previously, I had a post that said that the organizations that are claiming success with SOA probably had a culture that already had IT and business working together at a higher level. Therefore, I would expect that a business that realizes “the benefits of an agile, reusable, and loosely coupled architecture (even if they don’t call it that)” has a mature Enterprise Architecture practice, with IT having a seat at the strategic planning table. If that’s the case, it would be even more surprising to find a huge gap between IT management and architecture and the actual IT execution. That tells me that some CIO, CTO, or Chief Architect is not doing their job very well.

In organizations where SOA is buried within IT, I would have expected that IT is buried within the organization. So, while all the problems that Ron describes would be accurate, the cultural issues actually ripple beyond IT. Those cultural barriers are a huge barrier, and it’s not just an IT problem, it’s a problem for IT and the business. If the business doesn’t think strategically, which you’d think would be required in order to understand the benefits of an agile, reusable, and loosely coupled architecture, how can can IT be expected to think strategically?

My pragmatic nature tells me that there are surely cases where IT is the problem. There are also cases where the business is the problem. There are cases where both groups are the problem, and there are cases where everything is well. The only real problem is when no one recognizes the problems that exist. It’s always better to deal with your own problems before you begin finger pointing at another organization. IT can be a barrier, and Ron’s article does call out some common problems so it’s definitely worth the read. Truth be told, however, if you’re struggling with your SOA efforts, odds are that there are things that need to be fixed both within the business and IT. Don’t try to boil the ocean, but rather, understand where you’re at, the things you need to work on, and set a realistic approach in motion for doing so.

More on Widgets and Gadgets

It’s always refreshing to see someone else thinking along the same lines as yourself. The latest case for me was Om Malik in the April 2007 issue of Business 2.0. His column for that issue is titled, “Putting Widgets to Work.” He feels that there is significant promise for corporate widgets. This sounds very familiar to my post last week on Widgets, Gadgets, etc. You can read the teaser on his blog here, or read the full article over at CNNMoney.com.

SOA, BI, and Knowing Your Customer

Strategy is an interesting beast. It typically begins at such a high level that it’s possible to make connections between virtually any goal and any effort of a strategic nature, like SOA. At the same time, simple connections between those goals and efforts can be of, well, strategic importance. For this entry, I wanted to take one of those typical goals and try to bring it into the world of SOA and make some of those connections. Some of you may read this and just go, “Well duh, that’s common sense” while others may find something of significant value. I’d really like to hear your feedback on this entry. Strategy is one of those areas where people would many people in the trenches want to contribute, yet ultimately feel disconnected from it or that it doesn’t impact them. At the other end of things, the strategy makers want things to ripple down the trenches and for individuals to know that they are contributing to strategic success, yet their work is easily dismissed as being “fluff” or “ivory tower.”

The topic for today is knowing your customer. There’s no doubt that many, many companies likely have some strategic goal that can be tied back to customer support. The March 2007 issue of Business 2.0 had an article on “The Quest for the Perfect Online Ad” and it all comes down to better targeted advertising, which in turn, means knowing your customers. I would venture to guess that most companies try to do this through some form of data warehouse and business intelligence system. So how does SOA come into the mix? There’s actually two ways that I envision it having a role. First, it can enable a greater level of visibility into customer actions, presuming there’s some system interaction associated with the customer’s actions (sorry brick and mortar guys, not much SOA can do). Let’s presume that the system they use is a monolithic application. Your only source of input are the boundaries of the solution. If it’s a web application, you’ll have a clickstream, which can be pretty good, as evidenced by the levels of personalization from Amazon.com. If it’s a thick app, you may be limited to just extracting information from your transactional store, representing only the end outcome of the user’s efforts.

SOA, if done properly, should make it much easier to capture the user’s actions for later analysis. You’ll break down that monolithic application into a collection of services. These services represent boundaries within the solution, and at those boundary points you can leverage standardized infrastructure to log incoming requests and outgoing responses. This is even better than a web clickstream, because there you have to recreate the web page and understand what data elements were shown to the user on the page. If you’ve got the service request and response that returned the raw data tagged with the customer identifier, you’ve saved yourself a bunch of work associated with removing the presentation components. By pulling those messages into your BI system and analyzing the content of the message, you should begin to gain more knowledge about your customers.

The second way that SOA should come into play is in providing access to the data warehouse and business intelligence system to personalize the user experience. Rather than strictly being a source of reporting information for some person to look at, the information gleaned from those systems can be made available as services and factored back into the interface presented to the customer.

You may read this and think this is all common sense, and I actually hope that’s the case. Sometimes, however, we’re so buried in the technology or tactical issues that we fail to take the time to think strategically. It would be very easy to build the application in a service oriented manner and never bother to make use of the fact that this content is available and could provide valuable information for improving the customer experience. This is part of thinking outside of the box and beyond the functionality at hand. Hopefully reading this entry, whether you think it is common sense or not, will help you do that!

External consumers and providers

James McGovern, in his links entry for April 11th posted this comment in regards to my entry on what SOA adoption actually means:

“A measurement that would be interesting is to ask enterprises how many services do you have that are consumed outside of your enterprise. The numbers would be dramatically lower…”

As I thought about this, it became more and more interesting. First, I definitely agree that the number of services is going to be dramatically lower, unless your company is already a service provider (think ASP), in which case, then it should constitute the majority of your service portfolio. What about other verticals, however? Certainly supply chain interactions will involve external entities. Truth be told, there’s lot of potential for interactions with partner companies. How many companies outsource payroll processing to ADP or someone else? I’d venture a guess that there are probably areas for commodity services in every vertical. Over time, things that once were competitive differentiators become commodities. Once that happens, a marketplace opens up for commodity providers that focus on operational excellence and low cost, and the companies that prefer to focus on customer service get rid of their homegrown infrastructure and leverage the commodity provider. Guess what, when that happens, the potential now exists for service interactions. I recently presented some introductory information on service concepts and described business services as services that both ones that represent the primary business functions as well as ones that support the primary business such as HR, payroll, etc. Technology clearly plays a big role in both.

You may be thinking, “No arguments on what you said, but James asked about services consumed by outsiders, not provided by outsiders.” Quite true, but again, I’d be willing to bet that the vast majority of these B2B interactions will require bi-directional communications. It may be the case that 90% of the time, the partner acts in the service provider role, but odds are that some of that processing will require them having the ability to make service calls back to you. At a minimum, some form of events should be flowing back into your infrastructure. The more information flow can be a circle, rather than a one-way line, the greater the potential for leveraging emerging technologies like CEP for continued innovation. If the information only flows one way, you severely restrict your ability to innovate based on that information.

Aside:James also posted some musings on Open Source and the possibilities of it playing a role in commodity vertical applications yesterday. If that happened, there would certainly have potential implications. It probably wouldn’t take long for someone to create a hosted solution for these open source offerings, again creating the potential for service interactions between the two companies.

The end result of my thinking on this is that if your thinking on SOA is constrained to inside your firewall, it won’t be very long at all before you need to extend that thinking, both as a consumer of services provided from the outside as well as a provider of services that will be consumed by the outside. Companies that make the claim that they’ve “adopted SOA” should have a view that encompasses all of it, regardless of whether their core business is being a service provider or not.

Podcast on Customer Loyalty

You can get a lot of blogging done in airports and on planes as evidenced by my output today. I’m currently listening to a great podcast from IT Conversations. This one is from the Adaptive Path series. It’s Lou Carbone, Founder, President, and Chief Experience Officer of Experience Engineering, Inc., speaking on Creating Customer Loyalty. Not only is he a great speaker with some great anecdotes, but the topic is very interesting, at least to me. Give it a listen.

The management continuum

Mark Palmer of Apama continued his series of posts on myths around the EDA/CEP space, with number 3: BAM and BPM are Converging. Mark hit on a subject that I’ve spoken with clients about, however, I don’t believe that I’ve ever posted on it.

Mark’s premise is that it’s not BAM and BPM that are converging, it’s BAM and EDA. Converging probably isn’t the right word here, as it implies that the two will become one, which certainly isn’t the case. That wasn’t Mark’s point, either. His point was that BAM will leverage CEP and EDA. This, I completely agree with.

You can take a view on our solutions like the one below. At higher levels, the concepts we’re dealing with are more business-centric. At lower levels, the concepts are more technology-centric. Another way of looking at it is that at the higher levels, the products involved would be specific to the line of business/vertical we’re dealing with. At the lower levels, the products involved would be more generic, applicable to nearly any vertical. For example, an insurance provider may have things like quoting and underwriting at the top, but at the bottom, we’d have servers, switches, etc. Clearly, the use of servers are not specific to the insurance industry.

All of these platforms require some form of management and monitoring. At the lowest levels of the diagram, we’re interested in traditional Enterprise Systems Management (ESM). The systems would be getting data on CPU load, memory usage, etc. and technologies like SNMP would be involved. One could certainly argue that these ESM tools are very event-drvien. The collection of metrics and alerts is nearly always done asynchronously. If we move up the stack, we get to business activity monitoring. The interesting thing is that the fundamental architecture of what is needed does not change. Really, the only thing that changes is the semantics of the information that needs to get pushed out. Rather than pushing CPU load, I may be pushing out the number of auto insurance quotes requested and processed. This is where Mark is right on the button. If the underlying systems are pushing out events, whether at a technical level or at a business level, there’s no reason why CEP can’t be applied to that stream to deliver back valuable information to the enterprise, or even better, coming full circle and invoking some automated process to take action.

I think that the most important takeaway on this is that you have to be thinking from an architectural standpoint as you build these things out. This isn’t about running out and buying a BAM tool, a BPM tool, a CEP tool, or anything else. What metrics are important? How will the metrics be collected? How do you want to perform analytics (is static analysis against a centralized store enough, or do you need dynamic analysis in realtime driven by changing business rules)? What do you want to do with the results of that analysis? Establishing a management architecture will help you make the right decisions on what products you need to support it.

SOA Consortium

The SOA Consortium recently gave a webinar that presented their Top 5 Insights based upon a series of executive summaries they conducted. Richard Mark Soley, Executive Director of the SOA Consortium, and Brenda Michelson of Elemental Links were the presenters.

A little background. The SOA Consortium is a new SOA advocacy group. As Richard Soley put it during the webinar, they are not a standards body, however, they could be considered a source of requirements for the standards organizations. I’m certainly a big fan of SOA advocacy and sharing information, if that wasn’t already apparent. Interestingly, they are a time-boxed organization, and have set an end date of 2010. That’s a very interesting approach, especially for a group focused on advocacy. It makes sense, however, as the time box represents a commitment. 12 practitioners have publicly stated their membership, along with the four founding sponsors, and two analyst firms.

What makes this group interesting is that they are interested in promoting business-driven SOA, and dispelling the notion that SOA is just another IT thing. Richard had a great anecdote of one CIO that had just finished telling the CEO not to worry about SOA, that it was an IT thing and he would handle it, only to attend one of their executive summits and change course.

The Top 5 insights were:

  1. No artificial separation of SOA and BPM. The quote shown in the slides was, “SOA, BPM, Lean, Six Sigma are all basically on thing (business strategy & structure) that must work side by side.” They are right on the button on this one. The disconnect between BPM efforts and SOA efforts within organizations has always mystified me. I’ve always felt that the two go hand in hand. It makes no sense to separate them.
  2. Success requires business and IT collaboration. The slide deck presented a before and after view, with the after view showing a four-way, bi-directional relationship between business strategy, IT strategy, Enterprise Architecture, and Business Architecture. Two for two. Admittedly, as a big SOA (especially business-driven SOA) advocate, this is a bit of preaching to the choir, but it’s great to see a bunch of CIOs and CTOs getting together and publicly stating this for others to share.
  3. On the IT side, SOA must permeate the organization. They recommend the use of a Center of Excellence at startup, which over times shifts from a “doing” responsibility to a “mentoring” responsibility, eventually dissolving. Interestingly, that’s exactly what the consortium is trying to do. They’re starting out with a bunch of people who have had significant success with SOA, who are now trying to share their lessons learned and mentor others, knowing that they’ll disband in 2010. I think Centers of Excellence can be very powerful, especially in something that requires the kind of cultural change that SOA will. Which leads to the next point.
  4. There are substantial operational impacts, but little industry emphasis. As we’ve heard time and time again, SOA is something you do, not something you buy. There are some great quotes in the deck. I especially liked the one that discussed the horizontal nature of SOA operations, in contrast to the vertical nature (think monolithic application) of IT operations today. The things concerning these executives are not building services, but versioning, testing, change management, etc. I’ve blogged a number of times on the importance of these factors in SOA, and it was great to hear others say the same thing.
  5. SOA is game changing for application providers. We’ve certainly already seen this in action with activities by SAP, Oracle, and others. What was particularly interesting in the webinar was that while everyone had their own opinion on how the game will change, all agreed that it will change. Personally, I thought these comments were very consistent with a post I made regarding outsourcing a while back. My main point was that SOA, on its own, may not increase or decrease outsourcing, but it should allow more appropriate decisions and hopefully, a higher rate of success. I think this applies to both outsourcing, as well as to the use of packaged solutions installed within the firewall.

Overall, this was a very interesting and insightful webinar. You can register and listen to a replay of it here. I look forward to more things to come from this group.

ROI and SOA

Two ZDNet analysts, Dana Gardner and Joe McKendrick, have had recent posts (I’ve linked their names to the specific posts) regarding ROI and SOA. This isn’t something I’ve blogged on in the past, so I thought I’d offer a few thoughts.

First, let’s look at the whole reason for ROI in the first place. Simply put, it’s a measurement to justify investment. Investment is typically quanitified in dollars. That’s great, now we need to associate dollars with activities. Your staff has salaries or bill rates, so this shouldn’t be difficult, either. Now is where things get complicated, however. Activities are associated with projects. SOA is not a project. An architecture is a set of constraints and principles that guide an approach to a particular problem, but it’s not the solution itself. Asking for ROI on SOA is similar to asking for ROI on Enterprise Architecture, and I haven’t seen much debate on that. That being said, many organizations still don’t have EA groups, so there are plenty of CIOs that may still question the need for it as a formal job classification. Getting back to the topic, we can and do estimate costs associated with a project. What is difficult, however, is determining the cost at a fine-grained level. Can you determine the cost of developing services in support of that project accurately? In my past experience, trying to use a single set of fine-grained activities for both project management and time accounting was very difficult. Invariably, the project staff spent time that was focused on interactions that were needed to determine what the next step was. These actions never map easily into a standard task-based project plan, and as a result, caused problems when trying to charge time. (Aside: For an understanding on this, read Keith Harrison-Broninski’s book Human Interactions or check out his eBizQ blog.) Therefore, it’s going to be very difficult to put a cost on just the services component of a project, unless it’s entire scope of the project, which typically isn’t the case.

Looking at the benefits side of the equation, it is certainly possible to quantify some expected benefits of the project, but again, only a certain level. If you’re strictly looking at IT, your only hope of coming up with ROI is to focus on cost reduction. IT is typically a cost center, with at best, an indirect impact on revenue generation. How are costs reduced? This is primarily done by reducing maintenance costs. The most common approach is through a reduction in the number of vendor products involved and/or a reduction in the number of vendors involved. More stuff from fewer vendors typically means more bundling and greater discounts. There are other options, such as using open source products with no licensing fees, or at least discounted fees. You may be asking, “What about improved productivity?” This is an indirect benefit, at best. Why? Unless there is a reduction in headcount, the cost to the organization is fixed. If a company is paying a developer $75,000 / year, that developer gets that money regardless of how many projects get done and what technologies are used. Theoretically, however, if more projects are completed within a given time, you’d expect that there is a greater potential for revenue. That revenue is not based upon whether SOA was used or not, it’s based upon the relevance of that project to business efforts.

So now we’re back to the promise of IT – Business agility. For a given project, ROI should be about measuring the overall project cost (not specific actions within it) plus any ongoing costs (maintenance) against business benefits (revenue gain) and ongoing cost reduction. So where will we get the best ROI? We’ll get the best ROI by picking projects with the best business ROI. If you choose a project that simply rebuilds an existing system using service technologies, all you’ve done is incurred cost unless those services now create the potential for new revenue sources (a business problem, not a technology problem), or cost consolidation. Cost consolidation can come from IT on its own through reduction in maintenance costs, although if you’re replacing one homegrown system with another, you only reduce costs if you reduce staff. If you get rid of redundant vendor systems, clearly there should be a reduction in maintenance fees. If you’re shooting for revenue gain, however, the burden falls not to IT, but to the business. IT can only control the IT component of the project cost and we should always be striving to reduce that through reuse and improved tooling. Ultimately, however, the return is the responsibility of the business. If the effort doesn’t produce the revenue gain due to inaccurate market analysis, poor timing, or anything else, that’s not the fault of SOA.

There are two last points I want to make, even though this entry has gone longer than I expected. First, Dana made the following statement in his post:

So in a pilot project, or for projects driven at the departmental level, SOA can and should show financial hard and soft benefits over traditional brittle approaches for applications that need integration and easy extensibility (and which don’t these days?).

I would never expect a positive ROI on a pilot project. Pilots should be run with the expectation that there are still unknowns that will cause hiccups in the project, causing it to run at a higher cost that a normal project. A pilot will then result in a more standardized approach for subsequent projects (the extend phase in my maturity model discussions) where the potential can be realized. Pilots should be a showcase for the potential, but they may not be the project that realizes it, so be careful in what you promise.

Dana goes on to discuss the importance of incremental gains from every project, and this I agree with. As he states, it shouldn’t be an “if we build it, they will come” bet. The services you choose to build in initial projects should be ones that you have a high degree of confidence that they will either be reused, or, that they will be modified in the future but where the more fine-grained boundaries allow those modifications to be performed at a lower cost than previously the case.

Second, SOA is an exercise in strategic planning. Every organization has staff that isn’t doing project work, and some subset of that staff is doing strategic planning, whether formally or informally. Without the strategic plan, you’ll be hard pressed to have accurate predictions on future gains, thus making all of your ROI work pure speculation, at best. There’s always an element of speculation in any estimate, but it shouldn’t be complete speculation. So, the question then is not about separate funding for SOA. It’s about looking at what your strategic planners are actually doing. Within IT, this should fall to Enterprise Architecture. If they’re not planning around SOA, then what are they planning? If there are higher priority strategic activities that they are focused on, fine. SOA will come later. If not, then get to work. If you don’t have enterprise architecture, then who in IT is responsible for strategic planning? Put the burden on them to establish the SOA direction, at no increase in cost (presuming you feel it is higher priority than their other activities). If no one is responsible, then your problem is not just SOA, it’s going to be anything of a strategic nature.

Ads

Disclaimer
This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.