The Real Impact of IT Owning Your SOA Effort
I had a great lunch discussion today regarding the impact of ownership of SOA within the business. As I have discussed multiple times, SOA is about business services, not technical services, but the reality of this point is lost in semantics. The following illustrates the different perspectives that each have and how that impacts the overall SOA initiative.
Let's look at two business capabilities in real estate: renting the building space (sales) and drawing up rental agreement (legal). Each of these business capabilities are effectively services to the business. In order to operate effectively, they need to share some basic data, such as property listings and renter information (CRM). They also operate synchronously as part of a business process that results in the execution of a rental of a property. Otherwise, they operate fairly autonomously from each other.
From the business' perspective, at a minimum, they'd like one and only one of each of these capabilities, each delivering in a consistent manner. Sometimes, that is not possible. Perhaps, there needs to be two distinct sales teams due to regulatory or licensing issues. In this case, the business will still want the multiple sales teams all operating in a consistent manner, using the same forms, if possible, and interacting with the legal department to draw up the contracts in a consistent manner. The consistency is what enables the business to operate efficiently even in the face of redundancy.
In this particular case, I believe, while not optimal, it is perfectly okay for there to be redundancy of certain information systems in the delivery of each of these business capabilities as long as it allows the business function to deliver consistently and efficiently. For example, if each of these groups had selected a different portal product to provide access to the property listings, that would be acceptable as long as they were operating off the same listings service. Forcing these groups to consolidate on a single portal product is not going to provide any additional efficiencies for these groups or simplify their ability to deliver.
However, what we see happening in the industry, is that SOA efforts are being led by IT and not by the business leaders. Hence, IT views the problem from a systems perspective and sees the need to remove redundancy at the information systems level. So, instead of focusing on business capabilities and making sure that the business rules, processes and goals are being executed consistently and that redundant business capabilities are consolidated, they look at the redundant portals and identify them as a target for consolidation, as so they should. ITs job is to keep IT costs down and are rewarded by simplifying the work of the IT department. However, as I used to remind my developers, it's not about what's easier to code, it's about making the jobs of the users easier, that's why they pay us.
The result of IT forcing consolidation of portal products is some cost savings, but interruption and change for the business. The overall productivity losses within the business function due to the interruption is typically never identified, let alone measured. Users will need to be re-trained on the new portal, things won't work initially and users will become frustrated and be less productive. All of this for the possibility of reducing the costs of managing one additional piece of software.
I say let sleeping dogs lie. There are plenty of real information management costs in most businesses that eliminating will offer a real benefit to the business' bottom line. Clearly, both of the aforementioned business capabilities need to be operating off the same customer and listing data. There's plenty of work to be done by IT without focusing on needless change. Eliminating the additional software licensing costs are penny-wise, pound foolish when the real impact is analyzed and assessed.
With regard to SOA, IT will view SOA as an IT effort that results in consolidation of technical capabilities. That's their task and that's how they are rewarded. IT is not rewarded for improving productivity in payroll by improving the end of month process. And, therein lies the flaw in the system. We have become heavily reliant upon our data and applications to run our business, and therefore, IT has become a critical function of the business. Yet, the business world rewards IT for running with as low of an overhead that can be comfortably be achieved without putting the business at significant risk. If we really expect SOA to live up to its promise, it is going to have to become an effort that is undertaken by the line of business as they reorganize for streamlined operations, or, if we're going to let IT own the SOA, then we are going to have reward IT for improving productivity and usability of the systems in a manner that is best for the users and not necessarily IT. That is, we're going to have to let them focus on actually aligning the information systems with the needs of the business and not force the business to live with the limitations of the systems.
The Busy Executive’s Service Oriented Architecture Reference Guide
Based on feedback from my last blog entry, "The Busy Executive's Quick Cloud Computing Reference Guide" the consensus was that people found it very helpful as a means of gaining quick understanding of what Cloud Computing is without getting mired in heaps of technology jargon and hype. So, I decided that SOA needed something very similar. After all, there's so much confusion and misunderstanding of SOA in the market right now.
Let's start with a basic understanding of a service. There are lots of things that you can call services, which is where many of the problems arise for SOA. I believe that the use of the word service in context of "Service Oriented Architecture" connotes a particular meaning that filters out most of non-applicable definitions of services. To further illustrate this meaning, I will discuss services in the context of software services so as to clarify the differences between SOA and not-SOA.
First, SOA is an architectural approach designed to identify and delineate business functional boundaries within a particular domain. A domain can be a single organizational unit or an entire industry. Regardless of the domain, if there are interactions within the domain, then there is most likely more than one unique business functions used to complete those interactions.
Many times, and more often with larger domains, there is more than one way to accomplish a particular task or objective. When a domain is required to support multiple paths to a singular end, it has been identified that the redundancy has an associated cost. Removing that redundancy results in efficiencies and cost savings. Very simply, SOA is the initiative designed around identifying the domain goal, marking the necessary business functions boundaries required to reach that goal, consolidating these business functions so that there is no redundancy and then orchestrating the process to reach the goal against the resulting set of business functions. The identified business functions are your services. Note, without these business functions you cannot complete your mission and achieve your task.
Most people agree on the following regarding desirable attributes of a service. We use them to do work for us that we don't want to do, we want them to be consistent and reliable, we want to pay a fair price to use them and we don't want to own them, and we don't expect to still be responsible for part of the job after hiring the service. If you hired a landscape service for your house that was supposed to prune your shrubs and you still had to go out on the weekends and clip the hedges, chances are you'd fire that service provider.
All the "chatter" in the media and on the Internet would have you believe SOA is very complex and requires expensive software and expensive resources when all we're doing is looking at a particular domain and figuring out how we can chop it up into a group of services that work together. For example, a landscape service and a mulching service have particularly good synergy, would you agree? These are two distinct services, but they have what we call a loosely-coupled relationship. That is, they work together for the duration of a task and then go their separate ways.
Granted, the task of looking at a domain and breaking it down into a set of services is a strategic skill that requires an experienced practitioner, but formulating the boundaries and putting the governance around those boundaries in place can be done by current management.
Now that we have these critical elements defined, let's compare three different topics of software that have all been associated or labeled SOA. Of the three, only one is truly SOA. These three topics are: Software-as-a-Service (SaaS), component-based software development and real SOA.
Why Isn't Software-as-a-Service a Service? To answer this, let's return to our agreed upon attributes of a service. SaaS meets one criteria we defined for a service—we want to pay a fair price to use them and we don't want to own them. However, most SaaS is just rented software. You're still responsible for integrating your data with the SaaS application after you rent it. You're still responsible for configuration of the forms and workflows after you rent it. For me, SaaS fails to meet the other key attributes of a service.
When many technologists and IT specialists discuss SOA, what they most often really mean is component-based software development. Many people in the IT industry have used the label SOA to describe a way to build software systems. This is possible, if the software represents critical business functions as we will explore shortly in the discussion of real SOA. However, in these conversations you will also hear things like SOA platforms and utility services. These are sure-fire indicators that the discussion has degraded into software design methodology and has left the realm of SOA.
Here's why there's no such thing as a "utility" service and it's just a software component. If the business itself would be less scalable or cease operation because the service is not available, then you have a service. If the mulching service doesn't show up when the landscaper is there, the landscaper cannot complete their task. Whereas, the utility service concept is a technological artifact of a software or solution design. The software providing the business service could exist without the existence of the utility service. The resulting solution may not be as modular of a design and, perhaps, not offer the service provider, the preferred level of agility and flexibility, but the service consumer would be no worse off than if you decided not to build a utility service, but instead, developed that business logic directly in to the software itself.
The last topic is SOA and real services that are comprised of software. The best way to describe this is to look at a couple examples of services that I have developed over the years.
The Alert Service – This is a software-based service that was used in data center management to notify personnel that a problem had occurred. A user or another piece of software could create an alert and it would send the notification via a number of mediums, such as pager, fax, phone, email and printed ticket. This software took care of the entire task, didn't have to be built for each individual usage and delivered the one and only one way to perform the task goal.
Zero Bond Calculator Service – This is a software-based service that provided various zero-coupon traders with a consistent means of quoting a zero coupon price. The service happened to be accessible via Excel, but could have been offered via phone or other mediums if necessary. The trader provided the inputs and the calculator service provided the pricing. It consolidated the various approaches to pricing used by each different trader, thus minimizing the overhead of the trading desk. Again, it took care of the entire task, didn't have to be built for each individual usage and delivered the one and only one way to perform the task goal.
In each of the aforementioned examples, the software represents a business function that was implemented using software because it was easily automated and reduced the need for human labor. However, because it was implemented in software, does not, in and of itself, make these services. It's the role they represent. These services allowed the business to reduce complexity, consolidate around one way of achieving a goal and do so in a way that was agile and flexible. Moreover, while they are not dependent upon one another to provide value to the business, one could easily see how they could work together synergistically to ensure high-availability of the zero coupon pricing calculator for traders.
That's SOA in a nutshell! Identify, consolidate, orchestrate and govern a set of business functions or capabilities.
The Busy Executive’s Quick Cloud Computing Reference Guide
As an executive, you may be hearing many different viewpoints about Cloud Computing; some of them promising significant IT cost reductions and reductions in capital expenditures. Similarly, you are hearing about the potential downsides of Cloud Computing, such as unexpected outages impairing your ability to operate or increased opportunity for data leakage and privacy and confidentiality breaches. Hence, I've put together this quick primer to provide busy executives with a non-vendor-oriented view of Cloud Computing realities.
Don't get caught off guard regarding all the technical complexities of developing and offering Cloud Computing services, the whole reason you're considering this option is so others will take care of these factors for you. Although you still need to be an educated consumer, you don't need to be in the weeds to ensure you're not caught with your pants around your ankles if you decide to use Cloud Computing services.
With regard to Cloud Computing, you will either be renting an application, renting IT infrastructure or completely outsourcing a business function. You will see these referred to by a number of different names, such as Software-as-a-Service, Platform-as-a-Service, Infrastructure-as-a-Service, etc., again, for you, if you're trying to understand the differences between these you are too deep in the weeds. Of note, when we say IT infrastructure, we are including network connectivity, electricity, cooling, power backup, etc., not just a CPU, memory and storage, so you need to incorporate those attributes into any financial comparisons.
- Are you considering the Cloud for non-mission-critical capabilities? If so, then most Cloud Computing vendors will meet your needs without great concern. Your biggest concern should be ownership of your data, which has multiple components. One component is ownership in the eyes of the government. There are rules the government has to follow to gain access to your data when it's stored on your premises, however, those rules have yet to be qualified if they extend to your Cloud service provider. The other aspect of ownership that has arisen with regard to Cloud Computing regards who owns the physical data representation you or your Cloud provider. While the answer should be dead-brained simple, the realities of this is unclear. Other things to be concerned about include extended outages that limit access to your data and the applications used to access that data and hidden costs for attempting to perform batch operations on your own data or incorrect charges if billing is based on usage.
- If you are seeking to use the Cloud for mission-critical capabilities, will the Cloud vendor sign a service-level agreement that includes an option for non-performance financial penalties? To me, this is the dividing line for the role of Cloud Computing in IT. One of the advantages of Cloud Computing for a service provider is to take advantage of volume and economies of scale. If onboarding new customers results in legal agreements and the potential for financial penalties, its going to be difficult for them to offer their services at a reasonable price point. Hence, finding a Cloud Computing vendor that is going to provide you the assurances you need for a mission-critical application may be difficult.
- Maintaining privacy and confidentiality is your responsibility. There's a lot of discussion and speculation regarding Cloud security. The truth is Cloud vendors will most likely hire more highly-skilled cybersecurity experts than you will. Also, there's a strong likelihood, based on statistics, that your network and systems are already compromised in some manner. So, the reality of the situation is the Cloud will not introduce a greater risk regarding confidentiality and privacy breaches and may offer a more secure environment than you can on your own. Moreover, it doesn't matter if the breach happens in the Cloud or on your own premises, the repercussions will be the same to your business.
The private Cloud option is a way for vendors to take advantage of the fear, uncertainty and doubt surrounding the Cloud and sell the same wares they are selling to Cloud Computing service providers to you. As an executive, this is a real simple one for you; ask the question of your management team, "Were we already seeking to improve utilization of our existing data center investments regardless of the emergence of Cloud Computing?" If the answer is no, then when those private Cloud vendors show up at your doorstep, hold up your palm facing them and say, "talk to the hand!" If the answer is yes, then by all means, advancements in virtualization, storage and blade technology will provide you greater utilization of compute resources at a lower cost and, usually, lower energy consumption. However, take note, this change requires new skills, which equates to training and hiring of appropriate resources to manage this configuration. It also means that there is a greater likelihood for improper configuration, which can lead to outages that take longer to fix and make it easier to compromise.
That's it! Simple, easy-to-understand and written to help the busy executive gain a handle on the key decisions regarding Cloud Computing without having to wade through all the technical, legal and financial details that are being bandied about on the Web.
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!"
The Reason Enterprise Architects Should Study Economics
Economics is the social science that studies the production, distribution, and consumption of goods and services and aims to explain how economies work and how economic agents interact. The really interesting thing about economics is that getting the right answer requires that you pose the right question. That is, if you choose to make conclusions based on casual observations of explicit cause/effect relationships, then your conclusions will seem logical and sound to most who will review them. However, only by ensuring that the cause/effect relationship holds up in the case where casual variables are changed, can you be sure that you have truly observed a phenomena and that the cause is accurate.
I've been reading Freakonomics (looking forward to Super Freakonomics when I'm done), and I'm astounded at how well Steven Levitt's approach to Economics could fit the needs of Enterprise Architecture. For example, in Freakonomics, Levitt uncovers the truth regarding many long-held beliefs, such as most drug dealers live at the poverty line or how little parenting actually impacts the outcome of a child. What helped to uncover these facts was asking the right question and identifying which variables in the equation needed to remain static to ensure a valid outcome. In many of the cases, Levitt undermines what many other Economists, experts and pundits before him rolled out as proven facts and only due to his keen mind and his approach to formulating the problem domain was he able to uncover that which his peers could not. To keep us focused, I won't discuss here how he discovered why violent crime rates dropped in the 90's, but needless to say well-held beliefs as to why were shredded by Levitt's innate ability to target just the right variables and "run the numbers."
If we apply Freakonomics-type analysis to current information technology markets, such as Cloud Computing, based on experts and pundits one would readily equate that: a) public Cloud Computing models offer a more cost-effective way to acquire computing resources; b) it's better to rent software than to own it and; c) in the future, all computing will be paid for based on usage versus ownership. Similarly, if you read the headlines of many tech publications, you would believe that: a) everyone is doing SOA; b) there are many successful SOA deployments and; c) SOA is the only approach to developing systems that you should consider. None of these conclusions are true in all cases, maybe in no cases, and, in fact, the real numbers would probably tell a very different story [I'm leaving this as an exercise to the reader since I want to focus this piece on the approach to EA, not the application of analysis to these issues]. These statements are being made arbitrarily based on extremely small sample sizes and are as valid as looking around you at a large business gathering noting all the iPhones and Blackberries, and concluding that iPhone & Blackberry must outsell all other phones, when in fact, their combined market share is a mere 3.0-3.5% of the overall mobile phone market.
In actuality, I see a lot of IT decisions being made using what, seemingly, is no more exploration than was used to determine that iPhones & Blackberries have a leading market share. It is the Enterprise Architect's role to ensure that the selection and approaches toward development of systems are sound relative to their business, not just other businesses. Moreover, where decisions are based on the work of other businesses' success, those successes need to be properly vetted to ensure that there is enough commonality between efforts, such that you could make the leap that your business will see similar results. Finally, assumptions and theories need to be tested by properly identifying the variables that need to remain static and then comparing; in essence normalizing the question to be homogenous in all situations. For example, in Freakonomics, Levitt points out that in order to prove that the numbers behind why violent crimes dropped in the 90's he needed to review similar trends of violent crimes in areas that had not made the purported changes that led to the large unanticipated decrease. When the trends were normalized to remove noise and anomalies, it was shown that those factors seemed to have relatively little impact on violent crime decrease.
This brings us to the all important question, "how do we demonstrate the value of Enterprise Architecture?" Unfortunately, you cannot demonstrate the value of Enterprise Architecture if you cannot monetize or enumerate the value of all possible choices relative to the choices that are being recommended or those that have been made. Moreover, it's critical that these analyses are carried out over enough time that short-term wins don't supersede long-term potential gains. Thus, it is here that Enterprise Architects, especially those we call Chief Architects, truly show their mettle. It is their experience, coupled with the ability to focus on the right set of variables, understanding the impact of change of those variables and being able to communicate that in a way that allows the business to make effective business decisions, which sets top notch practioners apart from Sr. Software Engineers that the organization placated with a title to keep them happy so they wouldn't leave.
Response to InformationWeek’s Bob Evans Commentary on CIO Suicide
Bob Evans, senior VP and director of InformationWeek's Global CIO unit, recently published his thoughts and findings on why CIOs should no longer be focusing on aligning IT with business, but instead focusing on aligning with the customer. In this piece, Bob goes onto illustrate how some businesses have done some innovative things to increase revenues and drive brand with the help of their IT staff. The overall piece focuses on negative CIO stereotypes and goes so far as to indicate that attempting to align IT and the business is a red-herring that is not seen as strategic by the business and is unattainable.
To this, I say “Hooey!” IT/Business alignment can be as much as bunch of malarkey as it can be a powerful transformative force within the business. How successful an alignment effort is will be based on how well supported it is by the other executive managers. This piece just fosters more of that grotesque American desire for immediate gratification that has gotten us into the economic calamity we’re now in. It mirrors that borrow-and-consume mentality over save and spend conservatively.
Good IT/Business alignment is an INVESTMENT in the businesses future. However, with CEO’s only focused on their next quarter’s report to shareholders and how much they’re walking away with in bonuses, it’s no wonder that they would have no grasp or desire to spend on what might be (and should be) considered a long-term investment strategy. The software and systems that support the business need care and maintenance. If you create one of those newfangled, throw-it-up-in-a-week systems and your customers love it, you will need the appropriate design and infrastructure to scale it and keep it running. If you fail in this, your customers will sting you quickly and painfully, because they too are hooked on that immediate gratification buzz and have no stomach for your temperamental application that is limited by the 10 year old legacy application that is feeding it.
If your business is truly focused on its customers and interested in long-term strategies and quality, then you will select a CIO that has forethought into what customers need, but will ensure that the applications and infrastructure necessary to support those customers are there and have the proper levels of investments.
I would be remiss if I did not note that the businesses attitude toward IT from the start and awful selections for CIOs is a leading cause for negative CIO stereotypes and not their failed approaches to align IT with the business. A good CIO is actually a person that has good business subject matter expertise and a solid grasp of technologies and how to apply them to meet the needs of the business. Years of selecting the head of accounting is still plaguing the industry and will continue to until the business learns that the CIO needs to be more IT Consultant than a CFO.
The Role of The Business Analyst in an SOA World
Those of us that are part of SOA-related projects where traditional business analysts (BA) are involved often find ourselves frustrated by the incongruence between the analyst’s approach to requirements gathering and the SOA design. The problem arises because SOA models functionality of a business across multiple boundaries, whereas the business analyst wants to focus on a user’s needs. One focus is tactical and the other is strategic. However, more than this key difference, certain aspects of the tactical requirements overlap with the strategic requirements; specifically with regard to service boundaries. Thus, important business rules that are relevant to the definition of a particular service are buried among hundreds of irrelevant (to the SOA goals) requirements and the SOA architect is forced to mine these requirements like a miner mining for gold.
In figuring that someone else must have written on this topic, I visited my favorite Web search engine and pulled up the following article: “The new business analyst talks SOA”. I was surprised to find this content on Network World given the nature of the topic, but quickly realized that the author thought of SOA as an application architecture instead of an aspect of Enterprise Architecture. So, it was not much more of a surprise when they recommended that business analysts needed to become more savvy in SOA by learning BPEL, SCA and SDO; perhaps the worst advice I have ever seen regarding this topic. The last thing we want are the business analysts talking about SOA, let alone SODA aspects of SOA.
Still, the article had one point correct, business analysts had better be reading the signs and acclimating themselves to a different type of conversation with their users. Moreover, I believe SOA is a game changer in the way that we collect requirements going forward. For businesses that really want to be successful with SOA, the first conversations that need to be had are with the key business stakeholders, and an Enterprise Architect with SOA experience must be present and facilitating these discussions. This will be the basis for formulating a service model, which will then guide all future system designs. I would also engage a business process engineer to start analysis of business processes that directly impact the effort.
Ultimately, if a BA is able to make the transition to SOA mindset, then they might be a good candidate to drill down and analyze the requirements for the service contract and vocabulary for each service. Otherwise, an SOA architect should really handle these efforts. Which begs the question, what is the role of the BA in an SOA world? I believe there is a need for really good subject matter experts that can work with the Enterprise and SOA architects to fully define the interactions between business functions and, perhaps, to capture the usability models. However, even in the case of usability, a usability expert will offer more insight into how to present information to the user than the BA.
Overall, my analysis is that in an SOA universe, the role of the BA is greatly diminished unless they can adapt to the change in role and gain an understanding of how to facilitate requirements gathering in a much more compartmentalized manner as outlined by the SOA architect and the business process engineer.
The SOA (& Cloud) Funding Dilemma
Lately, and primarily among government users, I've been hearing about a potential clash of bureaucracy meets technology when it comes to funding shared services. It seems that the current government procurement and funding processes do not favor strategic sharing of software services as an outgrowth of a single development effort. I imagine that this issue might also arise in some large organizations where the business units are funding development using a self-funded IT organization, but I have yet to hear any specific stories coming from the private sector regarding this issue.
While there seems to be a number of workarounds to this problem, the basic issue still remains. If one government customer funds the development of an application out of their budget, and in developing that application, it is decided that one or more services could be of use to other government customers, there may be budgetary concerns for actually developing, hosting and maintaining those services for those that are not the original funding customer. Moreover, it becomes questionable how to go about adding features to those services when the requests are not coming from the original funding customer.
With all these government agencies pushing SOA in their IT strategies, one has to wonder, what exactly are they asking for? If the goal is not to remove redundancy within a single department and within a single agency--we're not even focusing on cross-agency here--as a means of reducing costs and providing a single means of delivering a business function in a non-ambiguous manner, then what is the goal?
From my own personal experiences, I believe certain agencies do desire to achieve the benefits of SOA, while others are simply seeking the benefits of component-based architecture, which is flexibility and agility in application design to lower costs of maintenance. However, due to "management by magazine" approaches in IT coupled with the "slap SOA on everything" mandates, agencies that are capable of only benefiting from component-based architecture--because of the procurement and funding issues or just basic needs--are now requesting SOA and ending up spending a lot more to develop a simple application than they should have in the first place and getting a lot more complexity and reliance on middleware infrastructure that is, at best, using a sledgehammer to kill a flea.
Now, most of this entry discusses the issue with regard to SOA, since this is where the problem has really become apparent recently. However, it's not too far of a leap to envision that Cloud Computing, that bastion of shared compute power, is going to have similar and more complex hurdles to overcome with regard to maintenance and operations of applications running in the Cloud. At the end of the day, someone responsible for budgeting today is going to have to figure out how much is required to support and maintain one of their applications next year. That may not be too difficult a task when they are the only group consuming that application, but the budgeting process is far more difficult when that agency accidentally becomes a SaaS provider to other agencies and departments interested in using that application.
Got any private or public sector stories regarding how the budgeting and procurement processes are hindering the strategic value SOA? Please share them with me as I am really interested in understanding the full boundaries of this issue.
Perhaps SOA is More Strategy Than Architecture
On Thursday, September 10th, 2009, I moderated a panel at the 1105 Group's Enterprise Architecture Conference in Washington, DC entitled, “SOA Goes Mainstream - An Industry and Government Roadmap.” On the panel we had two Federal government agency representatives and two industry representatives, with one of the industry representatives providing a FedEx case study as the basis for their SOA experiences.
As expected, each of the panelists' SOA experiences was varied, with no two taking an identical approach. However, the interesting tidbit of information I garnered from moderating this panel is that after a couple of years of effort, some approximation of a methodology that is termed “SOA”, which is specific to each organization, emerged and started delivering value to the organization.
Granted, I have been one of the louder proponents calling for agreement on the use of the term ‘SOA’ because I believe that without common agreement a term is relatively meaningless—I still believe this is true. However, in opening myself up to the idea that SOA may be more of a concept than an actual architectural approach, it became clear to me that that each organization may also organically formulate their own approximation of SOA that meets the needs of their business as functional components, or services. Moreover, each business’ approach toward SOA will most likely look completely different than any other business’ approach, their pain points will be different and their approach toward measuring success will be different.
For me, this is a startling revelation surrounding SOA. If one looks at the supporting industry infrastructure that has built up around the term SOA—software, training, methodologies, blueprints, etc.—the realization that each organization may ultimately need to tailor the general concepts into something that is different from organization to organization, minimizes these efforts to nothing more than templates or patterns to use as a starting point. Moreover, it’s quite possible that the only consistent aspect of SOA from organization to organization may be the road to adoption.
This also raises the need to re-evaluate earlier claims regarding the “Death of SOA” and SOA’s “trough of disillusionment.” If a consistent part of each organization’s early SOA efforts is represented by this tailoring effort, then perhaps some of these early failures are nothing more than part of the process analogous to the caterpillar spinning its cocoon and then working its way into becoming a butterfly. It does seem from my research that there is a consistent pattern among SOA adopters that successes seem to be more prevalent in the second and third years of SOA initiatives. Moreover, if we know this information going into an SOA effort, we can better manage expectations of the business with regard to Return-on-Investment (ROI) and time frames. Most of all, if the tailoring effort is a known part of the process, then unrealistic expectations can be removed from the practitioners, allowing them to focus on reaching successful ends.
Note, this realization does not mitigate the enterprise architecture efforts that must accompany, or more accurately, precede an SOA effort in order to ensure success. This realization is focused solely on the transformation of the business based on the EA artifacts and a building a service-oriented methodology to support that transformation. Thus, SOA is effectively the transition plan for the organization to maximize its resources, applying a ‘once-and-only-once’ mantra toward development efforts and align the technology imperatives with the business goals and functions.
So, based on this thesis, is SOA really architecture, or is it simply a strategy for business transformation?
The Impact of Making Product Choices Using Qualitative vs. Quantitative Analysis
As part of my job, I help customers to select the appropriate software to either fulfill a need or as a component of a larger solution. Fulfilling this role means comparing similar software offerings and selecting the best fit. The challenge in this goal is to map the vendor offering into a subjective requirement, such as "best fit".
Throughout my career I have acted in the role of consultant, architect and analyst. In each role, I have had the same challenge of identifying the best in particular product category. As a consultant/architect, the selection criteria was based on either an enterprise need or a single solution need. As an analyst, the challenge was a bit more difficult because the criteria was based on being a solution to a problem domain.
Ultimately, comparing and scoring different products can take two approaches: qualitative and quantitative. Both can be useful depending upon what you are looking to achieve. I have found that I prefer to be a qualitative analyst than a quantitative one because in most cases I find ratings useless and arbitrary, whereas a qualitative answer illustrates depth of reasoning for a particular outcome.
I once walked away from an assignment because the research firm wanted me to quantitatively compare CORBA, DCOM and RMI as distributed object computing frameworks. As much as I tried to explain, that they all have equal merit, the ultimate decision if one is better than the other is the environmental factors, not the individual technology. Unfortunately, that fell on deaf ears in a firm grounded in scaling each feature 1 - 10.
With regard to qualitative and quantitative analysis of particular products, it gets even more interesting when you start to get the vendors involved. A quantitative matrix usually entails requesting if a product supports a particular piece of functionality. For example, do you support LDAP. Having worked for multiple software vendors, I can tell you filling out these questionnaires by analyst groups can be an entertaining activity. While certain features are straightforward, there were plenty where the answers got as interesting as, "yeah, if we hang Jim out the 3rd story window on a windy day, while he's scratching his a$$, I think it we could do X." Hence, the resulting set of answers tells you if a vendor's product has a certain level of completeness, but it doesn't go into enough qualitative depth to decipher if the implementation is any good. Moreover, even if the implementation is good, does it fit the purpose for which it will be applied?
An additional benefit of doing qualitative analysis over quantitative, and one that is critical to product vendors, is that you can truly identify where products are differentiated. For example, many of the SOA platforms out there today, on the surface, all seem to provide similar functionality. What really differentiates them is intangible's, such as how much training is required for a developer to be productive or how easily can you build and deploy a service. Quantitatively, IBM's WebSphere's platform clearly wins time and time again when comparing SOA platforms on completeness, but if one explores how much training is required and how many steps are required to build and deploy a simple Hello World service, the simplicity of a Spring Web Services container becomes more attractive.
Ultimately, I believe that this divide is central in IT failures. Products are selected based on the wrong criteria. Products that are selected quantitatively, may not be the right product for a given environment. IT groups that go outside the "popular" choice and leader quadrant on the Gartner reports and look at how a particular product supports their specific needs for a given solution are often more successful. Additionally, while not popular due to how it increases product proliferation, businesses will be more successful if they stop overloading their product selections with Enterprise requirements and select their product more tactically. While this seemingly hurts the pocketbook, the losses in productivity and inefficiency--which is often not managed and, hence, difficult to compute--will outweigh the licensing and product management issues.
Disclaimer
My Most Recent Book
:Other Links
Web Profiles
Recent Posts
- Cloud Computing Pragmatics
- The Real Impact of IT Owning Your SOA Effort
- Architecture: 1000 ways to skin the cat, either way, the cat’s till dead
- The Busy Executive’s Service Oriented Architecture Reference Guide
- The Busy Executive’s Quick Cloud Computing Reference Guide
Tags
Recent Comments
- Steve Hughes on Cloud Computing Pragmatics
- CloudSigma on Cloud Computing Pragmatics
- Is ‘Service-Oriented Approach’ a Better Way to Define SOA? | SOA Governance - Service Oriented Architecture - SOA Business - SOA Design - SOA Services - SOA Software - SOA Solutions - SOA Security - SOA Web Service on Perhaps SOA is More Strategy Than Architecture
- Jaime Ramirez on The Busy Executive’s Quick Cloud Computing Reference Guide
- gon zalez on The Busy Executive’s Quick Cloud Computing Reference Guide
Blogroll
Other Links
Archives
- July 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- March 2009
- February 2009
- January 2009
- September 2008
- August 2008
- May 2008
- December 2007
- November 2006
- April 2005
