Monthly Archives: November 2009

Blogging Is My Civic Duty

Why do I blog?

For me it’s a civic duty. I have an ability to identify the real value of IT investments and directions to business. There’s a lot of noise out there coming from sources with their own agendas, both internal and external to an organization, that makes it difficult to fully understand the long term impact of any IT decision.

Overall, most IT failures have been washed away in short time spans, perhaps the IT leader suffered a political death in the organization, if not downright asked to leave, but overall the business does not abandon the solutions that are working, even if they are not working effectively. However, these continual failures do have an aggregate effect in wearing away confidence, which has an overall negative effect on the industry in which I make my living. As more business leaders lose faith that IT can be used to directly help them, the less inclined they are to spend and grow this industry.

I view my content as putting out some filters into the system to balance the noise. We all have an agenda, and mine is to improve the quality of information available to business decision makers regarding emerging directions in IT. However, my agenda is not self-serving with the exception of improving the entire community, thus, my information should be deemed trustworthy. Moreover, my blog, articles and community discussion input provide real discussion and enhance the overall quality of the conversation around these topics, which delivers greater value than reading a vendor-sponsored white paper.

The realities of the situation is this, executive business leaders need a system of checks and balances for IT acquisitions within their own organization. 99.999% of people attempt to forward their own agendas. Sometimes, those are aligned with the mission and sometimes they are not. Projects that are the equivalent of the “hail mary” play in the final seconds of the game to win, or promote oneself as the hero of the day, often end up being dropped passes that waste precious time and money. If I was a CEO or CFO that was not technically savvy, I’d make sure I had an advisor that could assess and provide objective feedback on the direction and decisions of IT management, which, by the way, is a great role for an Enterprise Architect.

My agenda is simple, improve the quality and reliability of solutions being provided by the IT industry as a whole. To make sure that IT decisions are vetted for economic feasibility and provide real value toward the mission of the organization. And, most of all, to raise the overall confidence of business in investing long-term IT investments that ensure continuity of the business in a world of growing uncertainty. While we cannot know what will happen tomorrow, we do have the ability to lay a foundation that will allow faster response to changes as they occur. Moreover, this goes beyond pure software, but the way we deliver IT as a service in general.

Desperately Seeking SOA Business Cases

The follow question was recently passed along to me by a peer:

“…There seems to be anecdotal evidence that moving a system to SOA, or creating a new system using that architecture is the right way to go but she was looking for something with numbers of metrics that she could use for her boss…”

This is a really important question because I believe that the person seeking this information is not alone in attempting to identify real value of investing in Service Oriented Architecture (SOA). The problem is that a properly done SOA should be unique to the mission, goals and processes of the organization making it of limited relative use to another organization. That is, SOA offers a framework for identifying, isolating, delivering and servicing a consumer need, and, while all businesses have some common aspects, the resulting business services should be unique to the needs of that business’ consumers.

So, what then is the real value proposition for SOA? The answer to this question is the age-old consulting answer, “it depends!”

For one thing, SOA is so poorly-defined that just about any IT project can be labeled SOA, which means that anything you want to place an SOA label on that enhances productivity, reduces costs, increases profitability or otherwise has delivered value to your business. One of the yardsticks I use to measure an SOA by is that the effort has produced “product”—by product I mean a tangible and achievable asset has been defined—that consolidates execution of a business function within the business in one of two ways; a) a consistent process that may be replicated but is executed identically, or b) the function is executed by a single unit within the business. Note, in some discussion of SOA you may see this represented as a requirement for reuse, but reuse is not our goal as reuse implies a choice to use or not use. We are seeking consistency and, what I call the need to have something built once-and-only-once, ergo, no choice; the service must be designed in a way to support its consumer audience completely.

In (a) above, it’s important to remain flexible in design. Some businesses are designed around their customer need, which means that a business function may need to be replicated due to privacy or confidentiality concerns. However, that does not mean that, where replicated, the function should not follow a consistent approach. The benefits and value of this to the business are significant. It allows employees to more easily be moved around, it reduces the costs associated with downstream processing and it simplifies the operations of the business for planning purposes. With regard to (b) above, that’s fairly self-explanatory. By consolidating multiple, different approaches to delivering the same business function within the organization, e.g. receivables handling, it will result in lower expenses and overhead.

I believe the key take away from this blog entry is that you can explore how others have succeeded in applying the steps I have outlined above, but you will need to seriously consider what it will take for your organization to leverage SOA design concepts to deliver value to your business. Moreover, the first decision you need to make is what improvements or value propositions matter most to your business, and NOT what SOA metrics exist to justify moving in that direction. Or, to rephrase that famous Kennedy quote, “ask not what SOA can do for you, but ask what you can do to improve your business!”