Linthicum's latest book: How SOA and cloud intersect for enterprise productivity benefits

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download a transcript. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Take the BriefingsDirect middleware/ESB survey now.

Welcome to the latest BriefingsDirect Analyst Insights Edition, Volume 45. This periodic discussion and dissection of IT infrastructure related news and events with industry analysts and guests, looks at a new book on cloud computing, a step-by-step guide on figuring out the right path to combined cloud and SOA benefits.

Dave Linthicum's new book, Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide, has just arrived and digs into the conflation of SOA and cloud computing. Our discussion with Linthicum on his findings is moderated by me, Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:

Linthicum: SOA is the way to do cloud. I saw early on that SOA, if you get beyond the hype that's been around for the last two years, is really an architectural pattern that predates the SOA buzzword, or the SOA TLA.

It's really about breaking down your architecture into a primitive state of several components, including services and data and processes., Then, it's figuring out how to assemble those in such a way that you can not only solve your existing problems, but use those components to resolve problems, as your business changes over time or your mission changes or expands.

Cloud computing is a nice enhancement to that. Cloud doesn't replace SOA, as some people say. Cloud computing is basically architectural options or ways in which you can host your services, in this case, in the cloud.

As we go through reinventing your architecture around the concept of SOA, we can figure out which components, services, processes, or data are good candidates for cloud computing, and we can look at the performance, security and governance aspects of it.

Architectural advantages

We find that some of our services can exist out on the platform in the cloud, which provides us with some additional architectural advantages such as self-provisioning, the ability to get on the cloud very quickly in a very short time without buying hardware and software or expanding our data centers, and the ability to rapidly expand as we need to expand basically on demand.

If we need to go from 10 users to 1,000 users, we can do so in a matter of weeks, not having to buy data-center space, waves and waves of servers, software, hardware licenses, and all those sorts of things. Cloud computing provides you with some flexibility, but it doesn't get away from the core needs to architecture. So, really the book is about how to use SOA in the context of cloud computing, and that's the message I'm really trying to get across.

... As we move toward cloud computing, there are more economical and cost-effective architectural options. There is also the ability to play around with SOA in the cloud, which I think is driving a lot of the SOA. In fact, I find that a lot of people build their first initial SOA as cloud-delivered systems, be it Amazon, IBM, Azure from Microsoft, and some of the other platforms that are out there.

Then, once they figure out the benefits of that, they start putting pieces of it on premise, as it makes sense, and put pieces of it on the cloud. It has the tendency to drive prototyping on the cheap and to leverage architecture and play around with different technologies without the investment we had to do in the past.

... We've got to stop the insanity. We've got control IT spending. We've got to be much more effective and efficient with the way in which we spend and leverage IT resources. Cloud computing is only a mechanism, it's not a savior for doing that. We need to start marching in new directions and being aggressively innovative around the efficiency, the expandability, and ultimately the agility of IT.

... When you're doing SOA and considering SOA within your enterprise or agency, you should always consider cloud as an architectural option. In other words, we have servers we're looking to deploy in middleware, we're looking to leverage in databases we're looking to leverage in terms of SOA. It's governance systems, security systems, and identity management.

Cloud computing is really another set of things that you need to consider in the context of SOA, and you need to start playing around with the stuff now, because it's so cheap. There's no reason that anybody who's working on an SOA shouldn't be playing around with cloud, given the amount of investment that's needed. It's almost nothing, especially with some of the initial forays, some of the prototypes, and some of the pilot projects that need to be done around cloud.

... Software as a service (SaaS) is probably the easiest way to get into the cloud. It also has the most potential to save you the greatest amount of money. Instead of buying a million-dollar, or a two-million-dollar customer reliationship management (CRM) system, you can leverage Salesforce.com for $50-60 a month.

After that, I would progress into infrastructures as a service (IaaS), and that's basically data center on demand. So, it's databases, application servers, WebSphere, and all those sorts of things that you are able to leverage from the data center, but, instead of a data center, you leverage it from the cloud.

Guys like Amazon obviously are in that game. Microsoft, or the Azure platform, are in that game. Any number of players out there are going to be able to provide you with core infrastructure or primitive infrastructure. In other words, it's just available to you over the 'Net with some of kind of a metering system. I would start playing around with that technology after you get through with SaaS.

. . . Instead of having to buy infrastructure and buy a server and set it up and use it, we could go get Google App Engine accounts or Azure accounts.

Then, I would take a look at the platform-as-a-service (PaaS) technology, if you are doing any kind of application development. That's very cool stuff. Those are guys like Force, Google App Engine, and Bungee Labs. They provide you with a complete application development and deployment platform as a service. Then, I would progress into the more detailed stuff -- database, storage, and some of the other more sophisticated services on top of the primitive services that we just mentioned.

... PaaS with that Google App Engine is driving a lot of innovation right now. People are building applications out there, because they don't have to bother existing IT to get servers and databases brought online, and that will spur innovation.

So, today, we could figure out we want to go off and build this great application and do this great thing to automate a business and, instead of having to buy infrastructure and buy a server and set it up and use it, we could go get Google App Engine accounts or Azure accounts.

Huge potential

Then, we can start building, deploying, defining the database, do the testing, get it up and running, and have it immediately. It's web based and accessible to millions of users who are able to leverage the application in a scalable way. It's an amazing kind of infrastructure when you think about it. The potential is there to build huge, innovative things with very few resources.

... Ten years ago, it was very difficult to do a start up. You'd have a million dollars in investment funds just to get your infrastructure up and running. Now, startups can basically operate with a minimal amount of resources, typically a laptop, pointing at any number of cloud resources.

They can build their applications out there. They can build their intellectual capital. They can build their software. They can deploy it. They can test it. Then, they can provision the customers out there and meter their customers. So, it's a great time to be in this business.

... There needs to be a lot of education about the opportunities and the advantages of using cloud computing, as well as what the limitations are and what things we have to watch out for. Not all applications and all pieces of data are going to be right for the cloud. However, we need to educate people in terms of what the opportunities are.

The fact of the matter is that it's not going to be a dysfunctional and risky thing to move pieces of our architecture out into cloud computing. Get them around the pilot. Get them to go out there and try it. Get them to basically experiment with the technology. Figure out what the capabilities are, and that will ultimately change the culture.

... We're going to get to a point where the data is going to be a ubiquitous thing. It doesn't really matter where it resides and where we can access it, as long as we access it from a particular model. It's not going to make any difference to the users either. I just blogged about that in InfoWorld.

In fact, we're getting into this notion of what I call the "invisible cloud." In other words, we're not doing application as a service or SaaS, where people get new interfaces that are web-driven. We're putting pieces of the back-end architectural components -- processes, services, and, in this case, data -- out on the platform of the cloud. It really doesn't matter to them where that data resides, as long as they can get at it when they need it.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download a transcript. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Take the BriefingsDirect middleware/ESB survey now.

Application transformation case study targets enterprise bottom line with eye-popping ROI

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download a copy. Learn more. Sponsor: Hewlett-Packard.

---

Gain more insights into "Application Transformation: Getting to the Bottom Line" via a series of HP virtual conferences Nov. 3-5. For more on Application Transformation, and to get real time answers to your questions, register to the virtual conferences for your region:
Register here to attend the Asia Pacific event on Nov. 3.
Register here to attend the EMEA event on Nov. 4.
Register here to attend the Americas event on Nov. 5.

---

This podcast is the first in the series of three to examine Application Transformation: Getting to the Bottom Line. Through a case study, we'll discuss the rationale and likely returns of assessing the true role and character of legacy applications, and then assess the true paybacks from modernization.

The ongoing impact of the reset economy is putting more emphasis on lean IT -- of identifying and eliminating waste across the data-center landscape. The top candidates, on several levels, are the silo-architected legacy applications and the aging IT systems that support them.

Using our case study, we'll also uncover a number of proven strategies on how to innovatively architect legacy applications for transformation and for improved technical, economic, and productivity outcomes. The podcasts coincidentally run in support of HP virtual conferences on the same subjects:

Register here to attend the Asia Pacific event on Nov. 3. Register here to attend the EMEA event on Nov. 4. Register here to attend the Americas event on Nov. 5.

Here to start us off on our series on the how and why of transforming legacy enterprise applications are Paul Evans, worldwide marketing lead on Applications Transformation at HP, and Luc Vogeleer, CTO for Application Modernization Practice in HP Enterprise Services. The discussion is moderated be me, Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:

Evans: When the economic situation hit really hard, we definitely saw customers retreat, and basically say, "We don't know what to do now. Some of us have never been in this position before in a recessionary environment, seeing IT budgets reduce considerably."

That wasn't surprising. ... It was obvious that people would retrench and then scratch their heads and say, "Now what do we do?"

Now we're seeing a different dynamic, ... something like a two-fold increase in what you might call "customer interest" [in applications transformation]. The number of opportunities we're seeing as a company has doubled over the last six or nine months.

If you ask any CIO or IT head, "Is application transformation something you want to do," the answer is, "No, not really." It's like tidying your garage at home. You know you should do it, but you don't really want to do it. You know that you benefit, but you still don't want to do it.

This has moved from being something that maybe I should do to something that I have to do, because there are two real forces here. One is the force that says, "If I don't continue to innovate and differentiate, I go out of business, because my competitors are doing that." If I believe the economy doesn't allow me to stand still, then I've got it wrong. So, I have to continue to move forward.

Secondly, I have to reduce the amount of money I spend on my innovation, but at the same time I need a bigger payback. I've got to reduce the cost of IT. Now, with 80 percent of my budget being dedicated to maintenance, that doesn't move my business forward. So, the strategic goal is, I want to flip the ratio.

... Today, we'll hear about a case study -- with the Italian Ministry of Instruction, University and Research (MIUR). This customer received an ROI in 18 months. In 18 months, the savings they had made -- and this runs into millions of dollars -- had been paid for. Their new system, in under 18 months, paid for itself. After that, it was pure money to the bottom-line.

... Our job is to minimize that risk by exposing them to customers who have done it before. They can view those best-case scenarios and understand what to do and what not to do.

Vogeleer: We take a very holistic approach and look at the entire portfolio of applications from a customer. Then, from that application portfolio -- depending on the usage of the application, the business criticality of the application, as well as the frequency of changes that this application requires -- we deploy different strategies for each application.

We not only focus on one approach of completely re-writing or re-platforming the application or replacing the application with a package, but we go for a combination of all those elements. By doing a complete portfolio assessment, as a first step into the customer legacy application landscape, we're able to bring out a complete road map to conduct this transformation.

We first execute applications that bring a quick ROI. We first execute quick wins and the ROI and the benefits from those quick wins are immediately reinvested for continuing the transformation. So, transformation is not just one project. It's not just one shot. It's a continuous program over time, where all the legacy applications are progressively migrated into a more agile and cost-effective platform.

The Italian Ministry of Instruction, University and Research (MIUR), is the customer we're going to cover with this case, is a large governmental organization and their overall budget is €55 billion.

This Italian public education sector serves 8 million students from 40,000 schools, and the schools are located across the country in more than 10,000 locations, with each of those locations connected to the information system provided by the ministry.

Very large employer

The ministry is, in fact, one of the largest employers in the world, with over one million employees. Its system manages both permanent and temporary employees, like teachers and substitutes, and the administrative employees. It also supports the ministry users, about 7,000 or 8,000 school employees. It's a very large employer with a large number of users connected across the country.

Why do they need to modernize their environment? In fact, their system was written in the early 1980s on IBM mainframe architecture. In early 2000, there was a substantial change in Italian legislation, which was called so-called a Devolution Law. The Devolution Law was about more decentralization of their process to school level and also to move the administration processes from the central ministry level into the regions, and there are 20 different regions in Italy.

This change implied a completely different process workflow within their information systems. To fulfill the changes, the legacy approach was very time-consuming and inappropriate. A number of strong application have been developed incrementally to fulfill those new organizational requirements, but very quickly this became completely unmanageable and inflexible. The aging legacy systems were expected to be changed quickly.

In addition to the element of agility to change application to meet the new legislation requirement, the cost in that context went completely out of control. So, the simple, most important objective of the modernization was to design and implement a new architecture that could reduce cost and provide a more flexible and agile infrastructure.

The first step we took was to develop a modernization road map that took into account the organizational change requirements, using our service offering, which is the application portfolio assessment.

From the standard engagement that we can offer to a customer, we did an analysis of the complete set of applications and associated data assets from multiple perspectives. We looked at it from a financial perspective, a business perspective, functionality and the technical perspective.

From those different dimensions, we could make the right decision on each application. The application portfolio assessment ensured that the client's business context and strategic drivers were understood, before commencing a modernization strategy for a given application in the portfolio.

A business case was developed for modernizing each application, an approach that was personalized for each group of applications and was appropriate to the current situation.

... This assessment phase took about three months with the seven people. From there, we did a first transformation pilot, with a small staff of people in three months.

After the pilot, we went into the complete transform and user-acceptance test, and after an additional year, 90 percent of the transformation was completed. In the transformation, we had about 3,500 batch processes. We had the transformation. We had re-architecting of 7,500 programs. And, all the screens were also transformed. But, that was a larger effort with a team of about 50 people over one year.

... We tried to use automated conversion, especially for non-critical programs, where they're not frequently changed. That represented 60 percent of the code. This code could be then immediately transferred by removing only the barriers in the code that prevented it from compiling.

All barriers removed

We had also frequently updated programs, where all barriers were removed and code was completely cleaned in the conversion. Then, in critical programs, especially, the conversion effort was bigger than the rewrite effort. Thirty percent of the programs were completely rewritten.

The applications are now accessed through a more efficient web-based user interface, which replaces the green screen and provides improved navigation and better overall system performance, including improved user productivity.

End-user productivity is doubled in terms of the daily operation of some business processes. Also, the overall application portfolio has been greatly simplified by this approach. The number of function points that we're managing has decreased by 33 percent.

From a financial perspective, there are also very significant results. Hardware and software license and maintenance cost savings were about €400,000 in the first year, €2 million in the second year, and are projected to be €3.4 million this year. This represents a savings of 36 percent of the overall project.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download a copy. Learn more. Sponsor: Hewlett-Packard.

---

Gain more insights into "Application Transformation: Getting to the Bottom Line" via a series of HP virtual conferences Nov. 3-5. For more on Application Transformation, and to get real time answers to your questions, register to the virtual conferences for your region:
Register here to attend the Asia Pacific event on Nov. 3.
Register here to attend the EMEA event on Nov. 4.
Register here to attend the Americas event on Nov. 5.

---

Global study: Hybrid model rules as cloud heats up, SaaS adoption blazing

“Cloud” is the game and “hybrid” is the name. A recent global study has encouraging news for cloud-computing enthusiasts, revealing a sharp uptick in the adoption, as well as consideration, of cloud computing. The same study also indicates that those who are adopting cloud aren’t going whole hog, but are taking a hybrid approach -- mixing external and internal clouds.

The study, commissioned by global IT consultancy Avanade, showed a surprising increase in the interest in cloud computing, even from a similar study conducted in January of this year. In January, 54 percent of respondents said they had no plans to adopt cloud computing. By September, that percentage had shrunk to 37 percent.

At the same time, the percentage of companies planning or testing cloud computing increased three-fold, going from 3 percent of respondents to 10 percent.

What’s significant in the report is that less than 5 percent of companies are using an all-cloud model. The rest are relying on a hybrid approach, and report security concerns as the chief factor for being cautious.

Nine months ago, 61 percent of respondents indicated that they were using only internal IT systems and today, that number has dropped to 41 percent. At the same time, those using a combined approach on a global level have increased to 54 percent from 33 percent nine months earlier.

The report says it not clear whether the hybrid model will lead to a pure-play adoption at some point.

SaaS is taking off

One aspect of cloud computing that’s finding wide adoption is software as a service (SaaS), with more than half of the respondents worldwide -- and 68 percent in the US -- reporting that they have adopted SaaS at some level. Despite extremely high satisfaction -- more than 90 percent -- reliability is still an issue. About 30 percent of respondents said they had lost more than a day of business due to a service outage.

Still, the reliability concerns haven’t dampened users’ enthusiasm for SaaS, and 62 percent of respondents reported that they had plans to move into more SaaS within the next year. However, similar to their experience with cloud, users tend to deliver SaaS applications internally, rather than from the third-party provider.

On a global basis, those who deliver SaaS application internally outnumber those who used a third party by a ratio of 2 to 1. In the US, that increases to 4 to 1. Also, those who do use SaaS often rely on multiple providers, with one third using three or more providers. This leads the report to conclude that there is opportunity in the SaaS market.

Other conclusion from the report:

• Cloud will continue to make significant inroads for the next year, although there won’t be a migration to a full cloud environment.
  
  
• The gap is closing between companies with plans to adopt and those without. Avenade sees those curves intersecting in 2011 or 2012.
  
  
• Despite the widespread adoption of cloud, there will be some applications that should remain on-premises.
  
  
• SaaS adoption will continue to spread and is spreading faster than other technologies have in the past.

The study was conducted by Kelton Research and surveyed 500 C-level and IT executives worldwide.

BriefingsDirect contributor Carlton Vogt provided editorial assistance and research on this post.

Here's why Apple is doing so well -- it's the top half, stupid

I've been ruminating the past few days on why Apple is doing so well with it's pricey high-end products and services during a recession. The answer came as I was reading today's New York Times column by Thomas Friedman, whom I deeply admire and read anything and everything he puts out.

Friedman points out that the winners in today's fast-shifting U.S. job market are the ones demonstrating "entrepreneurship, innovation and creativity." He says, "They are the new untouchables," in contrast to other still highly educated but less creative types.

Friedman cites Harvard University labor expert Lawrence Katz, who explains in the column that the now disadvantaged are "those engineers and programmers working on more routine tasks and not actively engaged in developing new ideas or recombining existing technologies or thinking about what new customers want. ... They’ve been much more exposed to global competitors that make them easily substitutable.”

They are also more likely to be using personal computers with nine-year-old operating systems, with little choice but to take what their companies provide in terms of personal productivity IT. They are the 90 percent for whom good enough IT has made them as good as anyone anywhere.

In contrast, it's the "top half" of the labor pool, and more specifically the apparent 10 percent that are "entrepreneurship, innovation and creativity"-focused among them, that know to succeed and win they need the very best computer and associated services, even if it costs $500 more. Nowadays there's no better way to gain an advantage in business and life than to have the best technology.

The people who are succeeding are buying Macs, iPhones, iPod Touches and Apple's services and applications. A flight to quality is usually spurred by disruption and uncertainty. It's not about brand religion or pretty graphics. It's about survival and success when the going gets tough. It works for me, it has to.

A chef doesn't buy the cheapest knifes. A painter doesn't buy the cheapest brushes. A carpenter doesn't buy the cheapest hammer. And all the winners in the economy today -- those that have a say in what they use to do all the digital things so critical now to almost any knowledge- and services-based job -- need the best tools. And they will upgrade those tools just as fast as they can (hence the rapid adoption of Apple's Snow Leopard OS X upgrade in recent months.)

So for all those millions of newly laid off workers who know that "entrepreneurship, innovation and creativity" is their only ticket to a new, fresh start -- those that no longer have an IT department to tell them what to do (at lowest cost) -- they seem to be making a new move to a Mac. I expect they won't soon go back, once they taste the fruits of heightened knowledge productivity.

Because when failure is not an option, you have to have the best tools, especially when the going gets tough. The sad part is that Apple does so well when so many are not.

SOA user survey defines latest ESB trends, middleware use patterns

Take the BriefingsDirect middleware/ESB survey now.

Forgive my harping on this, but I keep hearing about how powerful social media is for gathering insights from the IT communities and users. Yet I rarely see actual market research conducted via the social media milieu.

So now's the time to fully test the process. I'm hoping that you users and specifiers of enterprise software middleware, SOA infrastructure, integration middleware, and enterprise service buses (ESBs) will take 5 minutes and fill out my BriefingsDirect survey. We'll share the results via this blog in a few weeks.

We're seeking to uncover the latest trends in actual usage and perceptions around these SOA technologies -- both open source and commercial.

How middleware products -- like ESBs -- are used is not supposed to change rapidly. Enterprises typically choose and deploy integration software infrastructure slowly and deliberately, and they don't often change course without good reason.

But the last few years have proven an exception. Middleware products and brands have shifted more rapidly than ever before. Vendors have consolidated, product lines have merged. Users have had to grapple with new and dynamic requirements.

Open source offerings have swiftly matured, and in many cases advanced capabilities beyond the commercial space. Interest in SOA is now shared with anticipation of cloud computing approaches and needs.

So how do enterprise IT leaders and planners view the middleware and SOA landscape after a period of adjustment -- including the roughest global recession in more than 60 years?

This brief survey, distributed by BriefingsDirect for Interarbor Solutions, is designed to gauge the latest perceptions and patterns of use and updated requirements for middleware products and capabilities. Please take a few moments and share your preferences on enterprise middleware software. Thank you.

Take the BriefingsDirect middleware/ESB survey now.

Speaking of SOA: Are services nouns or verbs?

This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.

By Jason Bloomberg

ZapThink revels in stirring up controversy almost as much as we enjoy clarifying subtle concepts that give architects that rare "aha!" moment as they finally discern the solution to a particularly knotty design problem. Last month's "process isomorphism" ZapFlash, therefore, gave us a particular thrill, because we received kudos from enterprise architects for streamlining the connections between Business Process Management (BPM) and Service-Oriented Architecture (SOA), while at the same time, several industry pundits demurred, disagreeing with our premise that services should correspond one-to-one with tasks or subtasks in a process.

Maybe we got it wrong, and inadvertently mislead our following of architects? Or perhaps the pundits were off base, and somehow ZapThink saw clearly a best practice that remained obscure to other experts in the field?

Upon further consideration, the true answer lies somewhere in between these extremes. Now, we're not reconsidering the conclusions of the process isomorphism ZapFlash. Rather, further explanation and clarification is warranted.

As with any best practice, process isomorphism doesn't apply in every situation, and not every service should correspond to a process task or subtask. That being said, there is also a good chance that some of our esteemed fellow pundits might not be opining from a truly service-oriented perspective, as many of their comments hint at an object-oriented (OO) bias that may be too limiting in the SOA context.

In fact, understanding which services the process isomorphism pattern applies to, and how other services support such services goes to the heart of how to think about services from a SOA perspective.

The object-oriented context for services

In the early days of web services, as various standards committee members tried to hash out how core standards should support the vision of SOA, the SOAP standard for message transport was an acronym for the "Simple Object Access Protocol." The reasoning at the time was that services were interfaces to objects, and hence service operations should correspond to object methods, also known as remote procedures.

SOAP was nothing more than a simple, XML-based way of access those methods. Over time, however, people realized that taking this Remote Procedure Call (RPC) approach to service interfaces is too limiting: It leads to tightly coupled, synchronous interactions that constrain the benefits such services could offer. Instead, the industry settled on document style as being the preferred interface style, which expects requests and responses to conform to schemas that are included in the service contracts by reference, where the underlying service logic is responsible for validating interactions against the relevant schemas.

Document style interfaces provide greater loose coupling than their RPC-style cousins because many changes to a service need not adversely impact existing service consumers, and furthermore, document style interfaces facilitate asynchronous interactions where a request need not correlate immediately with a response. In fact, the W3C eventually dropped the "Simple Object Access Protocol" definition of SOAP altogether, and now SOAP is just SOAP, instead of being an abbreviation of anything.

The answer is straightforward: If a service has no operations, then what it's supposed to do is understood from the context of the service itself.

However, document style interfaces still allow for operations, only now they're optional rather than mandatory as is the case with RPC-style interfaces. The fact that operations are optional is a never-ending sense of confusion for students in our Licensed ZapThink Architect course, perhaps because of the object-oriented pattern of thinking many of today's techies follow, often without realizing it.

How would you ever know what a service is supposed to do, the reasoning goes, if you don't call an operation on that service? The answer is straightforward: if a service has no operations, then what it's supposed to do is understood from the context of the service itself. For example, an insurance company may want a service that simply approves a pending insurance policy. If we have an approvePolicy Service, the consumer can simply request that service with the policy number of the policy it wants to approve.

Nouns vs. Verbs

The insurance policy example brings up a fundamental question. Which is the service, the insurance policy entity or the approve policy task? In other words, should services be nouns or verbs? It's possible to design services either way, as Entity Services, which predictably represent business entities, or as Task Services, that represent specific actions that implement some step in a process, in other words, verbs. Which approach is better?

If you look at the question of whether services should be nouns or verbs from the OO perspective, then services are little more than interfaces to objects, and hence it's best to think of services as nouns and their operations as the verbs. For example, following the OO approach, we might have an insurance policy object with several operations, including one that approves the policy, as the following pseudocode illustrates:

myPolicy = new Policy (); ... successOrFailure = myPolicy.approve ();

The first statement above instantiates a particular policy, while the second one approves it, and returns either success or failure.

Now, it is certainly possible to create a Policy Service as an Entity Service that has an approve operation that works more or less like the example above, with one fundamental difference: because services are fundamentally stateless, you don't instantiate them. Here, then, is pseudocode that represents how an Entity Service would tackle the same functionality:

request to create new policy, specifying create policy operation --> Policy Service --> response with policy number 12345
...
request to approve policy 12345, specifying approve policy operation --> Policy Service --> response with success or failure

Note that we're representing service interactions as input and output messages that contain documents, where in this case, the input documents specify operations. In this example, there is no object in the OO sense representing policy 12345 and maintaining the state information that indicates whether or not that particular policy is approved or not.

Instead, the underlying service implementation maintains the state information. There is only the one Policy Service, and it accepts requests in the form of XML documents and returns responses, also in the form of XML documents. If a request calls the create policy operation, then the Policy Service knows to create the policy, while a request that specifies the approve policy operation follows the same pattern.

Note that the fact that the Policy Service has a document style interface gives us two advantages: First, we can make certain changes to the service like adding new operations without adversely impacting existing consumers, and second, its stateless nature enables asynchronous interactions, where instead of returning success or failure of the approve request, perhaps, the service returns a simple acknowledgment of the request (or perhaps no response at all), and then notifies the consumer at some point in the future that the policy has been approved, either through a one-way notification event or possibly as a response to a further query.

Task services as verbs

While there is a significant role for Entity Services in SOA, it is important to break free from OO-centric thinking and consider other types of services as well that serve other purposes. In fact, there is another way of offering the same functionality as the Entity Service above where the Services represent verbs rather than nouns, what we call Task Services. Here is the pseudocode for this situation:

request to create new policy --> createNewPolicy Service --> response with policy number 12345
...
request to approve policy 12345 -- > approvePolicy Service --> response with success or failure

In this example, neither Task Service has any operations, but rather the functionality of each Service is understood from the context of the Service. After all, what would an approvePolicy Service do but approve policies? If you read the process isomorphism ZapFlash, the benefits of delivering capabilities as Task Services is clear. If you design each Task Service to represent tasks or subtasks in business processes, then it's possible to build a service-oriented business application (SOBA) that is isomorphic to the process it implements.

Combining entity and task services

A casual reading of the process isomorphism ZapFlash might lead you to think we were suggesting that all services should be Task Services. However, in spite of the fact that architects with OO backgrounds often rely too heavily on Entity Services, such services do play a critical role in most SOA implementations.

Remember that in the enterprise context, services expose existing, legacy capabilities and data that are typically scattered across different applications and data stores, limiting the enterprise's agility and leading to high integration maintenance costs, poor data quality, reduced customer value, and other ills all too familiar to anybody working within a large organization's IT department. SOA provides best practices for addressing such issues by abstracting such legacy capabilities in order to support flexible business processes.

Both Entity and Task Services help architects connect the dots between legacy capabilities on the one hand, and flexible process requirements on the other, as the figure below illustrates:

Process, task, and entity service layers

In the figure above, the bottom row contains Entity Services, which directly abstract underlying legacy capabilities. Above the Entity Services lie the Task Services, which may actually be abstractions of individual operations belonging to underlying Entity Services. The top layer contains Process Services, which are typically compositions of Task Services. In other words, Process Services are interfaces to SOBAs, and when those SOBAs are compositions of properly designed Task Services, they will exhibit process isomorphism.

The essential question for the architect is which capabilities to abstract in which service layer. Take for example the Address Change Task Service. Changing addresses is a common example of a particularly challenging task in many large organizations, because address information is typically maintained by different applications and data stores in a haphazard, inconsistent manner. To make matters worse, there may be addresses associated with customers, policies, or other business entities.

When architecting the Customer Entity Service, the core design principle is to pull together the various instances of customer-related information and functionality across the as-is legacy environment into a single, consolidated representation. Such a Service will likely have an update address operation, and the Customer Entity Service's logic will encapsulate whatever individual queries and API calls are necessary to properly update customers' addresses across all relevant systems.

The Address Change Task Service, then, abstracts the Customer Entity Service's update address operation, as well as whatever other address change operations other Entity Services might have. The Service logic behind this Task Service understands, for example, that insured properties in polices have addresses and customers have addresses, and these addresses are related in a particular way, but are by no means equivalent.

The ZapThink take

As is usually the case, architects have several options at their disposal, and knowing which option is appropriate often depends on the business problem, an example of the "right tool for the job" principle. If the business problem is process-centric, say, a need to streamline or optimize the policy issuance process, then implementing SOBAs as compositions of Task Services will facilitate process flexibility.

In other cases, the business problem is more information-centric than process-centric, for example, putting consolidated customer information on a call center rep's screen. In such instances the architect's focus may be on an Entity Service, because the rep is dealing with a particular customer and must be able to interact with that customer in a flexible way.

The big picture of the SOA architect's challenge, of course, is delivering agility in the face of heterogeneity. On the one hand, the IT shop contains a patchwork of legacy resources, and on the other hand, the business requires increasingly agile processes. Understanding which capabilities belong in Entity Services and which belong in Task Services is a critical part of the best practice approach to SOA.

This guest post comes courtesy of Jason Bloomberg, managing partner at ZapThink.

---

SPECIAL PARTNER OFFER

SOA and EA Training, Certification,
and Networking Events

In need of vendor-neutral, architect-level SOA and EA training? ZapThink's Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.

Advanced SOA architects might want to enroll in ZapThink's SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.

---

What's on your watch list? Forrester identifies 15 key technologies for enterprise architects

Riding the right -- or wrong -- technology wave can help -- or really, really hurt -- your business. Moving at the right time can be the critical factor between the two outcomes.

Yet new technologies come down the pike at alarming speed. Deciding which will fizzle and which will sizzle -- and when -- can be a daunting and ongoing task. What’s an enterprise architect to do?

Forrester Research has tried to sort things out with a new report, “The Top 15 Technology Trends EA Should Watch.” And, if even limiting the selection to 15 sounds like a lot to keep your eye on, Forrester has grouped them into five major “themes,” and has ranked the technologies by their impact, newness and complexity.

Calling “impact” the most important criterion, the report says this considers whether the technology will deliver new business capabilities or allow IT to improve business performance.

“Newness” comes in second because it’s likely that enterprises will have to gear up to learn new processes and the processes themselves are prone to rapid evolution. “Complexity” places other demands on the business, requiring more time to learn operations that are more complex than others.

The five themes identified by Forrester, along with their associated technologies, are:

• Social computing in and around the enterprise
  
  
  • Collaboration platforms become people-centric
    
  • Customer community platforms integrate with business apps
    
  • Telepresence gains widespread use
  
  
• Process-centric data and intelligence
  
  
  • Business intelligence goes real time
    
  • Master data management matures
    
  • Data quality services become real-time
    
    
• Restructured IT services platforms
  
  
  • SaaS will be ubiquitous for packaged apps
    
  • Cloud-based platforms that become standard infrastructure and platform as a service
    
  • Client virtualization is ubiquitous
  
  
• Agile and fit-to-purpose applications
  
  
  • Business rules processing moves to the mainstream
    
  • BPM will be Web 2.0-enabled
    
  • Policy-based SOA becomes predominant
    
  • Security will be data- and content-based
  
  
• Mobile as the new desktop
  
  
  • Apps and business processes go mobile
    
  • Mobile networks and devices gain more power

The technologies range from real-time business intelligence (BI) with a very high impact, high newness and high complexity to data- and content-based security, which scored a medium in all three categories. I guess that'll keep my friend Jim Koblielus busy for some time.

Forrester limited the report to a three-year horizon for two reasons. First, it represents the planning horizon for most firms and, second, any technology that won’t have an effect in less than three years may be interesting, but it’s not actionable.

The report also says that we're entering a new phase of technology innovation. This analysis is based on Forrester’s finding that technology change goes through two waves. The first involves innovation and growth. This features a rapid evolution of the technology and rapid uptake by businesses. The second phase is refinement and redesign, in which technologies are only incrementally improved.

I hear a lot these day about "inflection points" in the IT market. I hear folks point to the hockey stick growth effect coming for netbooks/thin clients/desktop virtualization/Windows 7. I like to add the smartphones and Android-phones to that category too.

And even if the cloud is a slow burn, rather than hockey stick, the importance of business processes supported by services supported by all the old and new suspects is huge. I call the ability to refine and adapt business processes as the big productivity maker of the next decade --- supported by IT as services.

Perhaps the new Moore's Law is less about systems, and more about what people do with the services those systems enable. What do you think?

Incidentally, the full report is available for download from Forrester.

BriefingsDirect contributor Carlton Vogt provided editorial assistance and research on this post.

Making the leap from virtualization to cloud computing: A roadmap and guide

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download a copy. Learn more. Sponsor: Hewlett-Packard.

Get a free copy of Cloud for Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.

This latest BriefingsDirect podcast discussion focuses on enterprise IT architects making a leap from virtualization to cloud computing.

How should IT leaders scale virtualized environments so that they can be managed for elasticity payoffs? What should be taking place in virtualized environments now to get them ready for cloud efficiencies and capabilities later?

And how do service-oriented architecture (SOA), governance, and adaptive infrastructure approaches relate to this progression, or road map, from tactical virtualization to powerful and strategic cloud computing outcomes?

Here to help hammer out a typical road map for how to move from virtualization-enabled server, storage, and network utilization benefits to the larger class of cloud computing agility and efficiency values, we are joined by two thought leaders from HP: Rebecca Lawson, director of Worldwide Cloud Marketing, and Bob Meyer, the worldwide virtualization lead in HP’s Technology Solutions Group.

The discussion is moderated by me, BriefingsDirect's Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:

Lawson: We're seeing an acceleration of our customers to start to get their infrastructure in order -- to get it virtualized, standardized, and automated -- because they want to make the leap from being a technology provider to a service provider.

Many of our customers who are running an IT shop, whether it’s enterprise or small and mid-size, are starting to realize -- thanks to the cloud -- that they have to be service-centric in their orientation. That means they ultimately have to get to a place, where not only is their infrastructure available as a service, but all of their applications and their offerings are going in that direction as well.

Meyer: A couple of years ago, people were talking about virtualization. The focus was all on the server and hypervisor. The real positive trend now is to focus on the service.

How do I take this infrastructure, my servers, my storage, and my network and make sure that the plumbing is right and the connectivity is right between them to be agile enough to support the business? How do I manage this in a holistic manner, so that I don’t have multiple management tools or disconnected pools of data.

What’s really positive is that the top-down service perspective that says virtualization is great, but the end point is the service. On top of that virtualization, what do I need to do to take it to the next level? And, for many people now, that next level they are looking at is the cloud, because that is the services perspective.

Lawson: A lot of people are trying to make a link between virtualization and cloud computing. We think there is a link, but it’s not just a straight-line progression. In cloud computing, everything is delivered as a service.

What's really useful about cloud services like those is that they're not necessarily used inside the enterprise, but what they are doing is they are causing IT to focus on the end-game. Very specifically, what are those business services that we need to have and that business owners need to use in order to move our company forward?

... We're learning lesson from the big cloud service providers on how to standardize, where to standardize, how to automate, how to virtualize, and we're using the lessons that we are seeing from the big-cloud service providers and apply them back into the enterprise IT shop.

Meyer: The cloud discussion is important, because it looks at the way that you consume and deliver services. It really does have broader implications to say that now as a service provider to the business, you have options.

Your option is not just that you buy all the infrastructure components. You plumb them together, monitor them, manage them, make sure they're compliant, and deliver them. It really opens up the conversation to ask, "What’s the most efficient way to deliver the mix of services I have?"

The end result really is that there will be some that you build, manage, and manage the compliance on your own in the traditional way. Some of them might be outsourced to manage service providers. For some, you might source the infrastructure or the applications from the third-party provider.

... Then you start to understand the implications of shifting workloads, not losing specialty tools, and really getting to a point when you standardize. You could start to get to the point of managing a single infrastructure, understanding the costs better, and really be more effective at servicing and provisioning that. Standardizing has to happen in order to get there.

I'm not just talking about the server and hypervisor itself. You have to really look across your infrastructure, at the network, server, and storage, and get to that level of convergence. How do I get those things to work together when I have to provision a new service or provide a service?

... You're looking to source something for a service or you're looking to pull assets together. Everybody will have some combination of physical and virtual infrastructure. So how do I take action when I need a compute resource, be it physical or virtual?

Automation makes the transition possible

How do I know what’s available? How do I know how to provision it? How do I know to de-provision it? How do I see it if that’s in compliance?" All those things really only come through automation. From a bottom-up perspective, we look at the converged infrastructure, the automation capabilities, and the ability to standardize across that.

... When it’s gone beyond a server and hypervisor approach, and they've looked at the bigger picture, where the costs are actually being saved and pushed -- then the light goes on, and they say, "Okay, there is more to it than just virtualization and the server." You really do have to look, from an infrastructure perspective, at how you manage it, using holistic management, and how you connect them together.

Hopefully, at HP we can help make that progression faster, because we’ve worked with so many companies through this progression. But really it takes moving beyond the hypervisor approach, understanding what it needs to do in the context of the service, and then looking at the bigger picture.

Lawson: ... Most IT organizations want to be aware and help govern what actually gets consumed. That’s hard to do, because it’s easy to have rogue activity going on. It’s easy to have app developers, testers, or even business people go out and just start using cloud services.

... [But] if IT is willing and able to step back and provide a catalog of all services that the business can access, that might include some cloud services. We try to encourage our customers to use the tools, techniques, and the approach that says, "Let’s embrace all these different kinds of services, understand what they are, and help our lines of business and our constituents make the right choice, so that they're using services that are secure, governed, that perform to their expectations, and that don’t get them into trouble."

We encourage our customers to start immediately working on a service catalog. Because when you have a service catalog, you're forced into the right cultural and political behaviors that allow IT and lines of business to kind of sync up, because you sync up around what’s in the catalog.

There's no excuse not to do that these days, because the tools and technologies exist to allow you to do that. At HP, we’ve been doing that for many years. It’s not really brand new stuff. It’s new to a lot of organization that haven’t used it.

You can start to control, manage, and measure across that hybrid ecosystem with standard IT management tools. ... The organizing principle is the technology-enabled service. Then you can be consistent. You can say, "This external email service that we're using is really performing well. Maybe we should look at some other productivity services from that same vendor." You can start to make good decisions based on quantitative information about performance availability and security.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download a copy. Learn more. Sponsor: Hewlett-Packard.

Get a free copy of Cloud for Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.