Archive for the ‘Business’ Category

More on SOA Organizational Challenges

I just listened to Anne Thomas Manes’ podcast, “What Does it Take to Succeed With SOA?” that was released on Burton Group’s Inflection Point channel. One of the things that Anne pointed out is that many organizations do not have the right culture, especially on the business side, that promotes the sharing of services. A culture of sharing, collaboration, and trust is required to be successful. She also pointed out that the IT organization frequently mirrors the organization of the business, and if those business organizations don’t share, it makes it very difficult.

I started thinking about the organizational aspects of this. Many people in IT only have awareness of the highest levels of the business organization, and it may not be apparent that there’s a problem. But here are two common patterns that clearly point out the potential problems. First, there’s what I’ll call regionalization. Whether we’re dealing with global entities, or national companies with regional presence, it’s very likely that they have business units aligned along regions rather than along business capabilities. There may be very valid reasons for doing this, but it must also be recognized that they may all be performing the same business functions, only with the expected regional nuances. While it’s oversimplifying the problem, if a company sells widgets in 52 countries, there should be enough commonality to warrant some common services that all of them can leverage. Second, there’s product specialization. I have first-hand experience with an organization that had separate business units (and associated IT staff) for different products that the company offered. There were opportunities for shared services that were recognized within IT, but never made it to reality because of the cultural challenges within the organization. In this case, the cultural challenges were within IT, but it’s just as likely that the same challenges existed on the business side as well.

As Anne rightly points out in the podcast, somehow, we need to present the business value associated with the sharing. In some ways, this shouldn’t be any different than the value that makes companies choose to centralize sales and marketing. One of the big challenges faced within IT, however, it that the associated costs of redundant technology can be a bit harder to quantify. Yes, there are software licensing fees and maintenance agreements, but some of these one time costs are glossed over in deference to the project schedule. While I’ve never personally been involved with a centralization of sales and marketing, I’m guessing that a big part of the equation was an associated reduction in cost attributable to staff reduction, or in a more positive light, getting the cost to revenue ratio looking better by resource re-allocation. If we’re talking information technology, while it’s certainly a possibility, staff reduction doesn’t necessarily come into play, so that associated cost reduction must come from somewhere else, and at least in my experience, IT isn’t very good at quantifying it. So, across the board, our work is cut out for us, but that’s not to say it can’t be done. The one takeaway is to invest heavily in making your pitch. If you don’t have baseline metrics to be able to show the value improvement, whether in increased revenue or decreased cost, take the time to get them together before trying to make your pitch. It needs to be in terms the business can understand and is used to dealing with.

Organizing for SOA

On the Yahoo SOA group, there’s been a long conversation going on regarding (among other things) whether or processes operate at a higher level of abstraction than services which inevitably leads to a BPM first or SOA first debate. For the record, I don’t think that a process-centric approach necessarily leads to success. I made the point that I’ve seen first hand where a process-based viewpoint did nothing more than turn the silos 90 degrees. That is, where we previously had some capability locked away inside an application and only of value to that application, we now have the same capability locked away in a process, and only of value to that process. Both situations can be problematic. A service-centric approach, however, where we focus on a business capability and build outward focusing on consumption, seems to represent that “middle-out” approach.

Anyway, to get to the point of the post, a comment that both I and Anne Thomas Manes of the Burton Group made is that we’ve seen very few (in my case none) organizations that are structured around this notion of capabilities. Rob Eamon, a frequent commenter on this blog, replied to one of Anne’s messages (where she suggested that IT organize around capabilities) with this:

What does this really look like? Does the business organization line up in any way with the capabilities? What is the interaction between those responsible for business and those responsible for IT? Does business group A accept that “capability group X” has responsibility for business groups A, B, C, M, and N? So before capability X can be extended or changed, coordination is needed with all of them? Or is there a proliferation of different interfaces for X? …To paraphrase an old, old Byte magazine humor piece (, we have little information about hunting the elephants but lots and lots about packing the jeep.

I thought Rob’s message was great, and one that we should all think about. SOA isn’t a panacea for all things wrong in IT, and even more importantly, if it isn’t broken, don’t fix it. That being said, there’s also a lot of “well, we’ve been doing it this way for 20 years and nothing has fallen apart yet” mentality as well, and the right answer certainly lies somewhere in the middle.

Getting back to Rob’s message, he presents a scenario where 5 business groups all need a common capability. If this is the case, the question is how is that being handled today, and is it a problem? If all 5 groups have their own implementation of that capability, is that an issue or not? If the current organization handles that dependency fine, and the current path is in alignment with the long term strategy, why change anything? If it’s not in alignment with the long term strategy, then you have justification to change. The real disaster is when we don’t even know that those common capabilities exist. Then, you don’t even know whether you have a problem or not, and by the time you figure it out, you now lack the time to get it fixed. This is the situation where I think most organizations are. They’ve read the press and think SOA has potential. They know that there is room for improvement in the IT/Business relationship. Beyond that point, it gets really fuzzy. An integration-centric approach to SOA has some legs, but that really lives in the IT space and produces incremental gains, at best. Any other approach really requires some analysis of the business and the information technology that supports it to determine whether there’s value to be obtained or not. Unless someone has that view, it’s hard to say whether enterprise SOA will provide significant value or not. I’d go so far to say that it’s difficult to say whether anything of a strategic nature will provide significant value or not.

So, the question remains, how do you organize for SOA? Clearly, there’s no one answer. As many, many people have said, it has to start with the business and the things it’s trying to do. As Rob suggested in his message, simply changing the structure of IT may not be enough. If the business side hasn’t recognized that there are benefits to leveraging shared services, then anything IT does along those business capabilities may not help. Sure, there are some things that can be done strictly within IT, but those have more to do with the business of IT, than the true business. Any change in organization has to make sense for the business objectives, however. Take sales and marketing as an example. There are plenty of organizations that have shared sales and marketing, and plenty of organizations that have separate sales and marketing organizations along some other dimension. I think the same thing will likely hold true for organizing around SOA. Where the business needs dictate shared business capabilities, you adjust the organization, both business and IT. Where the business needs don’t, efforts to push SOA may run into resistance. If the business lacks the necessary domain knowledge to know where SOA can fit and where it may not, then it really doesn’t matter what structure you pick, it’s going to be a struggle.

More on Service Lifecycle Management

I received two questions in my email regarding my previous post on Service Lifecycle Management, specifically:

  • Who within an organization would be a service manager?
  • To whom would the service manager market services?

These are both excellent questions, and really hit at the heart of the culture change. If you look at the typical IT organization today, there may not be anyone that actually plays the role of a service manager. At its core, the service manager is a relationship manager- managing the interactions with all of the service consumers. What makes this interesting is when you think about exposing services externally. Using the concept of relationship management, it is very unlikely that the service manager would be someone from IT, rather, it’s probably someone from a business unit that “owns” the relationship with partners. IT is certainly involved, and it’s likely that technical details of the service interaction are left to the IT staff of each company, but the overall relationship is owned by the business. So, if we only consider internal services, does the natural tendency to keep service management within IT make sense? This approach has certain risks associated with it, because now IT is left to figure out the right direction through potentially competing requirements from multiple consumers, all the while having the respective business units breathing down their neck saying, “Where’s our solution?” At the same time, it’s also very unlikely that business is structured in such a way to support internal service management. Many people would say that IT is often better positioned to see the cross-cutting concerns of many of these elements. So, there are really two answers to the question. The first answer is someone. Not having a service owner is even more problematic than choosing someone from either IT or the business who may have a very difficult task ahead of them. The second answer is that the right person is going to vary by organization. I would expect that organizations whose SOA efforts are very IT driven, which I suspect is the vast lot of them, would pick someone within IT to be the service manager. I would expect that person to have an analyst and project management background, rather than a technical background. After all, this person needs to manage the consumer relationship and understand their requirements, but they also must plan the release schedule for service development. For organizations whose SOA efforts are driven jointly with the business, having a service manager within a business organization will probably make more sense, depending on the organizational structure. Also, don’t forget about the business of IT. There will be a class of services, typically in the infrastructure domains, such as authentication and authorization services, that will probably always be managed out of IT.

On question number two, I’m going to take a different approach to my answer. Clearly, I could just say, “Potential service consumers, of course” and provide no help at all. Why is that no help? Because we don’t know who represents those service consumers. Jumping on a common theme in this blog, most organizations are very project-driven, not service or product driven. When looking for potential service consumers, if everything is project driven, those consumers that don’t exist in the form of a project can’t be found! I don’t have a background in marketing, but I have to believe that there are probably some techniques from general product marketing that can applied within the halls of the business to properly identify the appropriate segment for a service. The real point that needs to be made is that a service manager can not take the field of dreams approach of simply building it, putting some information into the repository, and then hoping consumers find it. They have to hit the pavement and go talk to people. Talk to other IT managers whom you know use the same underlying data that your service does. Talk to your buddies at the lunch table. Build your network and get the word out. At a minimum, when a service is first identified, send a blast out to current project managers and their associated tech leads, as well as those that are in the project approval pipeline. This will at least generate some just-in-time consumers. While this may not yield the best service, it’s a start. Once some higher level analysts efforts have taken place to segment the business into business domains, then the right marketing targets may be more clearly understood.

IT as a Service Provider

The IT as a service provider discussion was brought back up by Joe McKendrick of ZDNet in this blog. In it, Joe made reference to a past blog of mine in which I stated my opinion that a customer/supplier relationship between IT and their end users in the business was a bad thing, and I still believe that. Joe’s post brought to light some small nuances on that opinion that need clarification.

In my original post, I stated that IT moving solely to a supplier model to the business is an invitation to be outsourced. If you’re simply an order taker, there’s no reason that someone else can’t take those orders. The value-add that an internal IT department provides is not technology expertise, but technology expertise combined with knowledge of the company. Any SaaS provider or outsourcing agency must provide services to a mass market, or at least a market with more than one customer.

Getting back to Joe’s post, the inference that could be made is that IT shouldn’t be a service provider. This is not the case however. The IT-Business relationship should be a partnership, but you can’t be a partner if you’re not providing good service. Understanding the services that you bring to the table and doing them well is critical to the relationship. The difference is that those services do not define the boundaries of the relationship. Instead, they bring structure and foundation to it, on which partnership can be built. If your foundation is weak, the relationship will crumble. Therefore, adopting principles of service management within IT is a good thing, however, don’t approach it from the standpoint of competing against outside service providers. The decision to use outside providers should be made by the business, which includes IT. IT should be the one driving the discussion to say, “some aspects of our technology are really becoming commoditized and we can achieve some significant cost benefits through an external provider” rather than being told, “you’re a commodity and we’ve outsourced you.” In this sense, IT is no different than other business support organizations. Take HR as a good example. One could certainly argue that HR could be outsourced as it provides commodity services that all companies need. Every large company I’ve been at still has an HR department, though. What is more the norm is to have HR working as part of the business to make good business decisions on what aspects of HR to outsource, and what aspects of HR should remain within the company because there is value add. Only someone within the company can really understand the corporate culture which is critical to attracting and retaining talented individuals.

Be a partner in your business, but ensure that your partnership is on a solid foundation.

Here Comes Another Bubble

Courtesy of Brandon Satrom, who I met here at the Gartner Summit, comes this hilarious YouTube video. If you don’t see it below, click here to go to YouTube.

Gartner EA Summit: Beyond the Business Case- Projects in the Enterprise Architecture

In this session, Robert Handler (of Gartner) is talking about the relationship between Enterprise Architecture and Project Portfolio Management (PPM). First off, there is clear overlap between the two efforts, provided that your PPM efforts are involved with the actual project definition and approval efforts, and not simply involved after project are approved and underway. Both efforts have the common desire to define projects that are intended to progress the company from a current state to a future state, although the criteria involved in project selection probably varies between the two.

On the PPM side, the biggest challenge is that this often isn’t happening. The survey quoted in the slides showed that the bulk of the time in PPM is spent mediating discussions on project priority, and just over 50% of the projects are even under the purview of the PPM effort. On the EA side, the slide states that most efforts are “mired in the creation of technical standards,” operating too much in a reactionary mode to current projects, and have very little effort on gap analysis. So, the end result is that neither effort is necessarily meeting their objectives, especially in the areas where they overlap, and neither effort is communicating well with the other.

He’s now showing an anchor model, and demonstrating how projects can be mapped onto the anchor model to show areas of concern and overlaps. I mentioned this anchor model in my blog entry on the Beginner’s Guide to Business Architecture session, and it’s jumping out again. This is definitely something that I need to get more information on, and hopefully start leveraging. He also presented a common requirements matrix and scoring approach which can assist in prioritization. The one challenge I see with this latter approach is that the projects all have to come along at the same time, which isn’t always the case. We’ll see if he gets to my question on this subject that I just submitted. (Note: he did, and pointed out that it doesn’t assume that everything comes in the same time, but that you do need to be willing to make adjustments to in-flight projects such as removing resources, altering scope, etc.)

Back to EA side of things, he’s advocating the use of patterns, principles, models, and standards as part of the architectural guidance that projects use. No arguments from me here. His slide also states that resource utilization in one organization went from 67% to over 80% when these are used effectively.

His closing recommendations are pretty straightforward. First, EA needs to be coordinated with PPM activities. Someone needs to take the first step to establish some synergies. Second, use coarse-grained EA deliverables for better project selection criteria. Third, use fine-grained EA deliverables on projects as gating factors. Fourth, capture some baselines and measure overall improvements, such as how long the design phase takes, productivity, etc. Finally, evolve maturity and effectiveness from where you are toward the ideal.

Overall, this was a very good session. It could have been a bit more prescriptive, but in terms of clearly showing the relationship between PPM and EA, it hit the mark.

Gartner EA Summit: Beginner’s guide to Business Architecture

I’m now in the Beginner’s Guide to Business Architecture session from Philip Allega. So far so good. He’s got a slide up right now showing an Anchor Model which presents a view that aligns nicely with my mental model of a diagram that shows the horizontal and vertical domains of the business. It’s nice to see something more formal than my own thoughts, and is exactly what I’m hoping to learn in this session.

The next components of a business architecture being discussed are principles and business domains. Interestingly, in doing technology architecture, I’ve worked with principles (technology-based, such as open-source vs. closed source, best of breed versus best fit, etc.) and technology domains. There’s really no difference in approach other than we’re now dealing with business principles (he gave the example of “No supplies will gain more than 5% of internal market share”) and business domains.

He’s now discussing roles that may be found in the BP & BA activities. There seems to be a strong correlation between BPI (Business Process Improvement) initiatives and Business Architecture. While he hasn’t come out and said that they are one and the same, it does make sense. If Business Architecture isn’t a once-and-done deal, then it makes sense that BPI is really just the continuous evolution of the Business Architecture.

The importance of continual learning

James McGovern responded to my Certified Architect

post with one of his own. He made a great point at the end of his entry which was something I wanted to discuss in my original post but didn’t find a way to work it in. He stated:

I guess the point that I am attempting to make is that certifications are neither good nor bad, and it is important to look at each within the context of the role you expect this individual to play. It is my belief that certifications don’t prove hands on skills at all, but having multiple at least says that there is evidence as an Enterprise Architect that you have the ability to learn as well as the desire…

Personally, I think the ability to learn, and learn quickly, is a critical skill for an architect. While some may think that architects spend all of their time up in clouds working on strategies and reference architectures, many of the architects I know are the go-to people when projects are struggling with decisions and direction. An architect needs to be able to quickly understand what it is that project is trying to do, determine what the most critical factors are, and provide appropriate guidance. At other times, it may not be the tactical project, but rather the senior executive asking the question, “should we be paying attention to any of this Web 2.0 and Social Networking hype?” The architect must quickly develop enough knowledge to make good decisions. Probably all architects will get stung at some point by some lower-level detail, but the good architects probably also take it in stride because they’re always learning.

When I interview people, I always ask a question about how the individual stays current, and it’s amazing how many people struggle with that question. If you’re not taking the time to learn, you’ll get left behind. I hope the readers of this blog learn things, and that’s a big reason why I do it. It’s even better when I get comments, links, or trackbacks, because I’m able to learn as well.

Business Case defines the Services, not SOA

In a article, Rich Seeley asked the question, “Who owns the SOA business case?” I think this is asking the wrong question. The business case should not be for SOA, but for the services. While some may read this and simply think that I’m nitpicking on semantics, I think it’s an important distinction. If the business case is for SOA, what’s the scope of that SOA? Is it an application architecture? An architecture that encompasses a line of business? An architecture that encompasses the entire enterprise?

The business case should provide the justification for what gets built. The services are what will be built. The article used the term “SOA project” numerous times, which is a pet peeve of mine. I don’t think there should ever be a “SOA project” as you can’t build a SOA. So, the reality is that we have business projects, which probably had an owner assigned the same way that it’s always been done for all business projects.  As part of the project, one or more services are going to be constructed. This equates nicely with Miko Matsumura’s analogy, where he described the interaction between an electrician and a home owner. The electrician likely knows more about the electrical system than the home owner, but the home owner is the one picking the actual light fixtures. Location may be a joint decision, as the home owner may not understanding implications of particular locations. The decision on what goes on in the walls is probably exclusively the responsibility of the electrician (based on the local building code). There are always exceptions. My father was an electrician in the Chicago area, so he and I have a preference for wires flowing through pipe rather than the use of romex, and may choose to have more say in that decision. The same may hold true for a tech-savvy business owner.

Both Tony Baer and Dana Gardner have posted blog entries in response to the article and get closer to the notion of what the right thing to own is. Dana suggests that ownership should reside at the business process level. This is one way of slicing it, but it’s not the only way, and therefore, it’s probably not the right way. In my opinion, ownership comes into play at many levels. A service can be shared across multiple applications. A service can be shared across multiple business processes. If ownership of the shared service is assigned to a single application or business process owner, there’s risk. The right way is to draw a line between business ownership of a service and business ownership of service consumers. You’ll probably need both. Now the risk associated with this approach is the number of individual owners may grow quite large. While I do think that an organization should try to make some determination up front on the potential for a service to be shared, I also know that whatever direction they go, things will change. So, it is important to have an idea on how to change ownership of a service after the fact. Just as a commercial organization may begin with “bundling” and eventually converge multiple products into one, so may be the case with services. If this makes sense to you, then you’re grasping an aspect of the problem that hasn’t been discussed yet, which is, “What does a service owner actually do?” The owner of the business case, and ultimately, the service, is not simply the source of funding and scope decisions for the project that builds version 1.0, but must be the owner of the whole service lifecycle from version 1.0 to the decommissioning of the last version, handling the onboarding of new consumers, “service” to existing consumers, etc.


Two recent posts by Jeff Schneider and Nick Malik, recently brought some attention to a very important aspect of SOA, which is funding it.

Jeff’s post, entitled “Budgeting for SOA” gives a great breakdown of all aspects of adopting SOA, which based on my experience, would certainly be a multi-year effort. He begins with establishing the SOA Foundation, which includes establishing a strategy, roadmap, reference architecture, and governance strategy, continues on with SOA Infrastructure Realization, establishing a SOA Governance Team, performing architectural analysis, training the staff, and then building the services and their consumers. Jeff articulates the costs associated with each of these for a typical organization based upon his experience.

Nick’s post, address the other side of this, which is where to find the money. In his post, SOA Economic Model: Avoiding Chargeback with Transaction Ration Funding, Nick calls out his disdain for chargeback models, and instead presents an alternate view whereby shared resources are funded out of a fixed operating budget that is funded through some form of flat tax. The teams that are funded by this pool are then allocated funds based upon the amount of transactions they process. While Nick presents a very simple model based upon the number of transactions, I’m sure other funding models could be used since a simple request count doesn’t take into account the complexity of the services, but his model is accurate in that it properly incents the service development teams. The teams that use the services are going to pay the tax no matter what, so they’re also now incented to make use of the services being provided, unlike a chargeback model whereby they pass less if they don’t use the shared services.

I think both of these posts do an excellent job of laying out the possibilities. Unfortunately, I wish more organizations were at the state where they have to worry about these factors. It seems that the vast majority of organizations are simply trying to build services out of existing efforts. Unless those efforts are sufficiently broad in scope (and surprisingly, many organizations I’ve seen do have at least one major initiative that typically qualifies), it’s unlikely that services will be created that will have broader applicability. Now I consider myself an optimistic person, but I also recognize that this is not an easy challenge. To get to what I envision and what Jeff and Nick describe represent fundamental changes in the way software development takes place. To do this will mean leveraging staff that already operates out of a shared funding model, such as enterprise architecture, since their efforts merely need to be assigned by the EA manager. If the EA group establishes the appropriate strategic models, smaller projects with limited scope can now demonstrate how the will contribute to broader strategic goals, thus warranting funding of shared services, versus doing things they way they’ve always been done. All of this comes back to something that I frequently bring up in discussions around SOA adoption. If the only thing that’s changed within IT is that the same old projects that we’ve been doing for years now are creating services within them, do we really expect to see any kind of dramatic change within IT, or will it just be chalked up as another overhyped trend? I, as an EA, certainly plan on doing everything I can to make sure that’s not the case. We have to be careful not to bite off more than the organization can chew at any given time, but we also need to make sure that we are the impetus for change.

Book Review

I had the opportunity to do a review of a book, and then discuss it in a podcast with the author and Dana Gardner. The book is entitled, “Succeeding with SOA: Realizing Business Value Through Total Architecture” and is written by Dr. Paul Brown of TIBCO Software.

You can view a transcript here, listen to the podcast here, or I’ve also added it as an enclosure on this entry.

I enjoyed this book quite a bit, and have to point out that it’s not your typical technology-focused SOA book. It presents many of the cultural and organization aspects behind SOA, and does a pretty good job. It tries to offer guidance that works within the typical project-based structures of many IT organizations. While I personally would like to see some of these project-based cultures broken down, this book offers practical advice that can be used today and eventually lead to the cultural changes necessary. Overall, I recommend the book. I found myself thinking, “Boy, if I were writing a book on SOA, these are things that I’d want to cover.” Give the podcast a listen, and check out the book if you’re interested.

Full disclosure: Outside of receiving a copy of the book to review, I did not receive any payment or other compensation for doing the review or participating in the podcast.


I finally decided to post regarding the Nucleus Research/KnowledgeStorm study that many of the SOA bloggers have been commenting about. In the InfoWorld article by Paul Krill, David O’Connell, senior analyst at Nucleus, is quoted as saying, “Only a minority of companies are getting a return on investment of SOA.”

Like many others, I don’t put a lot of faith in anything that tries to associate ROI and SOA. ROI should be addressed at the business initiative level, i.e. something with quantifiable business benefit. Opening up a new store location has quantifiable business benefits. The elimination of certain paperwork associated with an employee hiring process can have quantifiable business benefits. SOA isn’t a project, but rather it’s a way of approaching the technical solutions within a project. I can apply the principles of SOA to the automation of employee hiring processes. I can apply the principles of SOA to the technology pieces associated with opening a new store.

If we want to narrow the discussion to something more closer to where SOA can have an impact, we can look at development costs. As has been stated by others, however, this really only deals with the area of reuse. How do you capture the ability of IT to work closely with the business and save time on analysis because of the better mutual understanding of how technology and business come together? It should be reflected in lower development costs/quicker time to market. At this level, however, things get fuzzy. Ultimately, however, the more important point is whether or not business value is being produced. The development cost of the technology is just one piece of the puzzle in implementing a business solution. IT should always be striving to improve itself and continue to bring those costs down. Do you even know what these costs are? Are you collecting metrics about your development processes to know whether things are getting better or worse? Even if you want to attach ROI to SOA, if you don’t have the before and after numbers, all you’re getting is someone’s gut feeling.

This entry isn’t meant to say that we should simply ignore ROI and just do SOA because it’s the right thing to do. That sort of blind adoption can be just as damaging as not doing anything. The point is that discussions around ROI at the executive level should be about business benefits. You can’t just define and run an SOA project. You run business projects, and apply SOA within it. The ROI for the executives is based upon the ROI of the business project, of which SOA is just one piece.

iPhone in the Enterprise

Richard Monson-Haefel announced an upcoming telebriefing from the Burton Group that will ask the question, “Is the iPhone ready for the Enterprise?” I think this is going to be a very interesting discussion, and hopefully Richard will post a summary of the discussion after the fact for those of us that aren’t able to listen. It should be a great conversation, as they’re bringing analysts in from various services for the discussion.

Interestingly, with all of this talk about the iPhone and the enterprise, I actually think we’re asking the wrong question. It’s not about the iPhone, rather, it’s about how connected, mobile devices should be leveraged in the enterprise. Certainly, there are plenty of industries where mobile devices already play a key role. Just look at the technology associated with any company in the logistics industry for examples. The real discussion, however, is for those industries where the use of connected, mobile devices may not be immediately apparent. There are many enterprises that still have desktop machines for all employees and are just beginning to look at whether laptops should be issued, let alone consider something like the iPhone. Therefore, there is potential for a disruption in this space, something that could have a fundamental difference in how we go about our tasks.

The reason this discussion is gaining such momentum now, in my opinion, has everything to do with the full-browser capabilities of the iPhone. While I didn’t own a smartphone before getting an iPhone, I did have some experience with a Blackberry (before they had phone capabilities), and made extensive use of the WAP browser on my old Motorola V360. Email and access from the Blackberry was great, but that’s about it. Now, we’ve got this full web browser that can run a variety of web based applications (although not all, my kids can’t play with Webkinz on it due to no Flash, which is probably a good thing, at least as far as playing Webkinz goes). There’s a whole range of applications out there, as Richard calls out, the real potential is in applications developed specifically for the iPhone. Is this any better than some of the custom apps for one of the other smart phones? I’ve never written a mobile app, and I don’t know what limitations they have when the phone doesn’t have full web capabilities. I can only suspect that the recent hype on this subject is an indicator that only now have the doors really been opened. Connectivity is critical to these devices, otherwise they just become a PDA, which has certainly faded away. The question is whether connectivity + small form factor equals disruption. While I use the iPhone Facebook application, I’d hardly call it disruptive. There’s a killer app out there waiting to be written.

While I’m sure the conversation will focus more on the technical details around the iPhone in the enterprise, hopefully it will expand into the potential for mobile devices in the enterprise, whether it’s through a laptop with WiFi or wireless broadband or an device like the iPhone. Ultimately, this is what will decide whether it gets a place in the enterprise versus just being yet another way of getting to the corporate email and calendar.

Is a competition model good for IT?

Back in February, Jason Bloomberg of ZapThink posted a ZapFlash entitled “Competitive SOA.” I didn’t blog about it at the time, but this topic was brought back to the forefront of my mind by this post from Ian Thomas, with some follow-on commentary from Joe McKendrick.

While I’m not one to take one side or the other strongly, I must admit that I have significant reservations about a competition model, whether it is internal competition as suggested in the initial ZapThink article, or it is competition between IT and outside providers of services. First, let’s get the easy part of this out of the way. Part of Ian’s article is about simply running IT as a business and having good cost accounting. I’m certainly not going to argue about this. This being said, there’s a big difference between being a division or department of a company versus a supplier to a company.

I believe strongly that a customer/supplier relationship between IT and the end users of IT in the business is a bad thing, in most cases. If IT moves to exclusively to that model, the business leaders should clearly always be considering outsourcing IT completely. In doing so, it definitely sends a clear message that technology usage is not going to be a competitive advantage for this company. I believe that outsourcing can make sense for horizontal domains, where cost management is the most important concern.

The right model, in my opinion, is to have IT be part of the business, not a supplier to the business. To be part of a business, you need to be a partner, not a supplier. Brenda Michelson posted some excerpts from a Wall Street Journal interview with three CIO’s: Meg McCarthy of Aetna, Inc., Frank Modruson of Accenture Ltd., and Steve Squeri of American Express Co. Some great quotes from this:

Ms. McCarthy: At Aenta, the IT Organization is critical to enabling the implementation of our business strategy. I report to the chairman of our company and I am a member of the executive committee. In that capacity, I participate in all of the key business conversations/decisions that impact the company strategy and the technology strategy.

Mr. Squeri: I believe that over the next 10 years, the CIO will get more involved in the overall business strategy of the company and see their role expand in importance. The CIO will be increasingly called upon not only to translate business strategies into capabilities but to become even more forward-looking to determine what capabilities the business will need in the future.

The days of tech leaders as relationship managers and “order takers” will go by the wayside and they will be called upon to create and drive technology strategies that drive business capabilities.

It’s great to hear these leaders calling out how IT is becoming a partner, rather than a supplier. While our business leaders are certainly more tech-savvy than they have been in the past, there is still significant value in having people that specialize in technology adoption and utilization on your leadership team, just as you have people who specialize in sales, marketing, operations, etc.

Ian suggests letting “self interest flourish within the bounds set by the organisational context as long as it delivers cost-effective services but punish it by outsourcing where it doesn’t.” Cost reduction is just one factor in a complex decision. Holding the threat of outsourcing over IT may certainly in a more efficient operation, but applying those principles to areas where the decision shouldn’t be based on cost efficiency, but strategic impact to the business is a risky proposition. Let the business, which includes IT, decide what’s right to outsource and what isn’t. It shouldn’t be a threat or a punishment, but a decision that all parties involved agree makes good business sense.

Looking back on SOA from the future

Joe McKendrick asked the question in his blog, “How will we look back on SOA in 2020?” This is actually something I’ve been thinking about (well, maybe not 2020, but certainly the future) in preparation for the panel discussion at The Open Group EA Practitioners Conference next week.

One of the things that I’m very interested in is the emerging companies of today, and what their technology will look like in the future. So many companies today are having to deal with existing systems, focusing on activities such as service enablement. Largely, these exercises are akin to turning a battleship on a dime. It’s not going to happen quickly. While I’m fully confident that in 2020 many of these companies will have successfully turned the battleship, I think it will be even more interesting to see what companies that had a blank slate look like.

Dana Gardner recently had a podcast with Annrai O’Toole of Cape Clear Software, where they discussed the experiences of Workday, a Cape Clear customer. Workday is a player in the HR software space, providing a SaaS solution, in contrast to packaged offerings from others. Workday isn’t the company I’d like to talk about however. The companies that I’m more interested in are the ones that are Workday customers. Workday is a good example for the discussion, because in the podcast, Dana and Annrai discuss how the integration problems of the enterprise, such as communication between HR and your payroll provider (e.g. ADP), are now Workday’s problems. By architecting for this integration from the very beginning, however, Workday is at a distinct advantage. I expect that emerging companies with a clean IT slate will likely leverage these SaaS solutions extensively, if for no other reason than the cost. They won’t have a legacy system that may have been a vertical solution 20 years ago, but is now a horizontal solution that looks like a big boat anchor on the bottom line.

One thing that I wanted to call out about the Workday discussion was their take on integration with third parties. As I mentioned, they’ve made that integration their problem. This is a key point that shouldn’t be glossed over, as it’s really what SOA is all about. SOA is about service. The people at Workday recognized that their customers will need their solution to speak to ADP and other third parties. They could easily have punted and told their customers, “Sorry, integration with that company is your problem, you’re the one who chose them.” Not only is that lousy service, but it also results in a breakdown of the boundaries that a good SOA should establish. In this scenario, a customer would have to jury rig some form of data extract process and act as a middleman in an integration that would be much better suited without one. You have potentially sensitive data flowing through more systems, increasing the risk.

The moral of this story is that there are very few times in a company’s history where the technology landscape is a blank slate. Companies that are just starting to build their IT landscape should keep this in mind. I’ve blogged in the past on how the project-based culture where schedule is king can be detrimental to SOA. An emerging company is probably under even more time-to-market pressure, so the risk is even greater to throw something together. If that’s the case, I fear that IT won’t look much different in 2020 than it does today, because the way we approach IT solutions won’t have changed at all. Fortunately, I’m an optimist, so I think things will look significantly different. More on that at (and after) the conference.


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.