On The Insider: Britney's Bikini-Clad Top 10
BNET Business Network:
BNET
TechRepublic
ZDNet

Category: Application Lifecycle Management

November 16th, 2009

ZapThink explores the four stages of SOA governance that lead to business agility

Posted by Dana Gardner @ 7:09 am

Categories: Agile Development, Application Lifecycle Management, Cloud computing, HP, IBM, IT Management, IT Service Management, ITIL, Microsoft, Progress Software, SOA, SOA Governance, SOA architect, Software Development, Web Services, database, datacenters, governance, management

Tags: ZapThink LLC, Policy, SOA, SOA Governance, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Dana Gardner

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

By Jason Bloomberg

For several years now, ZapThink has spoken about SOA governance “in the narrow” vs. SOA governance” in the broad.” SOA governance in the narrow refers to governance of the SOA initiative, and focuses primarily on the service lifecycle.

When vendors try to sell you SOA governance gear, they’re typically talking about SOA governance in the narrow. SOA governance in the broad, in contrast, refers to IT governance in the SOA context. In other words, how will SOA help with IT governance (and by extension, corporate governance) once your SOA initiative is up and running?

In both our Licensed ZapThink Architect Boot Camp as well as our newer SOA and Cloud Governance Course, we also point out how governance typically involves human communication-centric activities like architecture reviews, human management, and people deciding to comply with policies. We point out this human context for governance to contrast it to the technology context that inevitably becomes the focus of SOA governance in the narrow. There is an important technology-centric SOA governance story to be told, of course, as long as it’s placed into the greater governance context.

One question we haven’t yet addressed in depth, however, is how these two contrasts — narrow vs. broad, human vs. technology — fit together. Taking a closer look, there’s an important trend taking shape, as organizations mature their approach to SOA governance, and with it, the overall SOA effort. Following this trend to its natural conclusion highlights some important facts about SOA, and can help organizations understand where they want to end up as their SOA initiative reaches its highest levels of maturity.

Introducing the SOA governance grid

Whenever faced with to orthogonal contrasts, the obvious thing to do is put them in a grid. Let’s see what we can learn from such a diagram:

The ZapThink SOA governance grid

First, let’s take a look at what each square contains, starting with the lower left corner and moving clockwise, because as we’ll see, that’s the sequence that corresponds best to increasing levels of SOA maturity.

1. Human-centric SOA governance in the narrow

As organizations first look at SOA and the governance challenge it presents, they must decide how they want to handle various governance issues. They must set up a SOA governance board or other committee to make broad SOA policy decisions. We also recommend setting up a SOA Center of Excellence to coordinate such policies across the whole enterprise.

These policy decisions initially focus on how to address business requirements, how to assemble and coordinate the SOA team, and what the team will need to do as they ramp up the SOA effort. The output of such SOA governance activities tend to be written documents and plenty of conversations and meetings.

The tools architects use for this stage are primarily communication-centric, namely word processors and portals and the like. But this stage is also when the repository comes into play as a place to put many such design time artifacts, and also where architects configure design time workflows for the SOA team. Technology, however, plays only a supporting role in this stage.

2. Technology-centric SOA governance in the narrow

As the SOA effort ramps up, the focus naturally shifts to technology. Governance activities center on the registry/repository and the rest of the SOA governance gear. Architects roll up their sleeves and hammer out technology-centric policies, preferably in an XML format that the gear can understand. Representing certain policies as metadata enables automated communication and enforcement of those policies, and also makes it more straightforward to change those policies over time.

This stage is also when run time SOA governance begins. Certain policies must be enforced at run time, either within the underlying runtime environment, in the management tool, or in the security infrastructure. At this point the SOA registry becomes a central governance tool, because it provides a single discovery point for run time policies. Tool-based interoperability also rises to the fore, as WS-I compliance, as well as compliance with the Governance Interoperability Framework or the CentraSite Community become essential governance policies.

3. Technology-centric SOA governance in the broad

The SOA implementation is up and running. There are a number of services in production, and their lifecycle is fully governed through hard work and proper architectural planning. Taking the SOA approach to responding to new business requirements is becoming the norm. So, when new requirements mean new policies, it’s possible to represent some of them as metadata as well, even though the policies aren’t specific to SOA.

Such policies are still technology-centric, for example, security policies or data governance policies or the like. Fortunately, the SOA governance infrastructure is up to the task of managing, communicating, and coordinating the enforcement of such policies. By leveraging SOA, it’s possible to centralize policy creation and communication, even for policies that aren’t SOA-specific.

Sometimes, in fact, new governance requirements can best be met with new services. For example, a new regulatory requirement might lead to a new message auditing policy. Why not build a service to take care of that? This example highlights what we mean by SOA governance in the broad. SOA is in place, so when a new governance requirement comes over the wall, we naturally leverage SOA to meet that requirement.

4. Human-centric SOA governance in the broad

This final stage is the most thought-provoking of all, because it represents the highest maturity level. How can SOA help with the human activities that form the larger picture of governance in the organization? Clearly, XML representations of technical policies aren’t the answer here. Rather, it’s how implementing SOA helps expand the governance role architecture plays in the organization. It’s a core best practice that architecture should drive IT governance. When the organization has adopted SOA, then SOA helps to inform best practices for IT governance overall.

The impact of SOA on enterprise architecture (EA) is also quite significant. Now that EAs increasingly realize that SOA is a style of EA, EA governance is becoming increasingly service-orientated in form as well. It is at this stage that part of the SOA governance value-proposition benefits the business directly, by formalizing how the enterprise represents capabilities consistent with the priorities of the organization.

The ZapThink take

T
he big win to moving to the fourth stage is in how leveraging SOA approaches to formalize EA governance impacts the organization’s business agility requirement. In some ways business agility is like any other business requirement, in that proper business analysis can delineate the requirement to the point that the technology team can deliver it, the quality team can test for it, and the infrastructure can enforce it. But as we’ve written before, as an emergent property of the implementation, business agility is a different sort of requirement from more traditional business requirements in a fundamental way.

A critical part of achieving this business agility over time is to break down the business agility requirement into a set of policies, and then establish, communicate, and enforce those policies — in other words, provide business agility governance. Only now, we’re not talking about technology at all. We’re talking about transforming how the organization leverages resources in a more agile manner by formalizing its approach to governance by following SOA best practices at the EA level. Organizations must understand the role SOA governance plays in achieving this long-term strategic vision for the enterprise.

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.


October 29th, 2009

Separating core from context brings high returns in legacy application transformation

Posted by Dana Gardner @ 12:46 pm

Categories: Agile Development, Application Lifecycle Management, Cloud computing, Developer Tools, Government, HP, Hardware Infrastructure, IBM, IT Management, IT Service Management, ITIL, SOA, SOA Governance, SOA architect, Software Development, Software Infrastructure, VMware, Virtualization, datacenters, governance, mainframe, management

Tags: Asset, Legacy Application, Hewlett-Packard Co., Legacy, Tool, Productivity, Podcasts, Operational Planning, Asset Management, Enterprise Software

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

This podcast is the second in a series of three to examine Application Transformation: Getting to the Bottom Line. Through panel discussions we examine the rationale and likely returns of assessing the true role and character of legacy applications, and then further determine the paybacks from modernization.

To gain the most return on modernization projects, many enterprises are separating core from context when it comes to legacy enterprise applications and their modernization processes. As enterprises seek to cut their total IT costs, they need to identify what legacy assets are working for them and carrying their own weight, and which ones are merely hitching a high cost — but largely unnecessary — ride.

A widening cost and productivity division exists between older, hand-coded software assets and replacement technologies on newer, more efficient standards-based systems. Somewhere in the mix, there are also core legacy assets distinct from so-called contextal assets. There are peripheral legacy processes and tools that are costly vestiges of bygone architectures. There is legacy wheat and legacy chaff.

With us to delve deeper into the high rewards of transforming legacy enterprise applications is Steve Woods, distinguished software engineer at HP, and Paul Evans, worldwide marketing lead on Applications Transformation at HP. The discussion is moderated be me, Dana Gardner, principal analyst at Interarbor Solutions.

The podcasts coincidentally run in support of HP virtual conferences on the same subjects:

Here are some excerpts:

Evans: This podcast is about two types of IT assets: core and context. That whole approach to classifying business processes and their associated applications was invented by Geoffrey Moore, who wrote Crossing the Chasm, Inside the Tornado, etc.

He came up in Dealing with Darwin: How Great Companies Innovate at Every Phase of their Evolution with this notion of core and context applications. Core being those that provide the true innovation and differentiation for an organization. Those are the ones that keep your customers. Those are the ones that improve the service levels. Those are the ones that generate your money. They are really important, which is why they’re called “core.”

When these applications were invented to provide the core capabilities, it was 5, 10, 15, or 20 years ago. What we have to understand is that what was core 10 years ago may not be core anymore. There are ways of effectively doing it at a much different price point.

As Moore points out, organizations should be looking to build “core,” because that is the unique intellectual property of the organization, and to then buy “context.” They need to understand, how do I get the lowest-cost provision of something that doesn’t make a huge difference to my product or service, but I need it anyway.

The “context” applications are not less important, but … you should be looking to understand how that could be done in terms of lower-cost provisioning [of them].

Woods: [A lot of the interest in separating core and context in legacy IT applications] has to do with the pain users are going through. We have had customers who had assessments with us before, as much as a year ago, and now they’re coming back and saying they want to get started and actually do something. So, a good deal of the interest is caused by the need to drive down costs.

Also, there’s the realization that a lot of these tools — extract, transform, and load (ETL) tools, enterprise application integration (EAI) tools, reporting, and business process management (BPM) — are proving themselves now. We can’t say that there is a risk in going to these tools. They realize that the strength of these tools is that they bring a lot of agility, solve skill sets issues, and make you much more responsive to the business needs of the organization.

… What I created at HP is a tool, an algorithm, that can go into any language legacy code and find the duplicate code, and not only find it, but visualize it in very compelling ways. That helps us drill down to identify what I call the unintended design. When we find these unintended designs, they lead us to ask very critical questions that are paramount to understanding how to design the transformation strategy.

… When you identify the IT elements that are not core and that could be moved out of handwritten code, you’re transferring power from the developers — say, of COBOL — to the users of the more modern tools, like the BPM tools.

So there is always a political issue. What we try to do, when we present our findings, is to be very objective. You can’t argue that we found that 65 percent of the application is not doing core. You can then focus the conversation on something more productive. What do we do with this? The worst thing you could possibly do is take a million lines of COBOL that’s generating reports and rewrite that in Java or C# hard-written code.

We take the concept of core versus context not just to a possible off-the-shelf application, but at architectural component level. In many cases, we find that this is helpful for them to identify legacy code that could be moved very incrementally to these new architectures.

… A typical COBOL application — this is true of all legacy code, but particularly mainframe legacy code — can be as much as 5, 10, or 15 million lines of code. I think the sheer idea of the size of the application is an impediment. There is some sort of inertia there. An object at rest tends to stay at rest, and it’s been at rest for years, sometimes 30 years.

So, the biggest impediment is the belief that it’s just too big and complex to move and it’s even too big and complex to understand. Our approach is a very lightweight process, where we go in and answer to a lot of questions, remove a lot of uncertainty, and give them some very powerful visualizations and understanding of the source code and what their options are.

… When you go to the legacy side of the house, you start finding that 65 percent of this application is just doing ETL. It’s just parsing files and putting them into databases. Why don’t you replace that with a tool? The big resistance there is that, if we replace it with a tool, then the people who are maintaining the application right now are either going to have to learn that tool or they’re not going to have a job.

If we get the facts on the table, particularly visually, then we find that we get a lot of consensus. It may be partial consensus, but it’s consensus nonetheless, and we open up the possibilities and different options, rather than just continuing to move through with hand-written code.

If you look at this whole core-context thing, at the moment, organizations are still in survival mode.

Evans: If you look at this whole core-context thing, at the moment, organizations are still in survival mode. Money is still tight in terms of consumer spending. Money is still tight in terms of company spending. Therefore, you’re in this position where keeping your customers or trying to get new customers is absolutely fundamental for staying alive. And, you do that by improving service levels, improving your services, and improving your product.

… The line-of-business people are now pushing on technology and saying, “You can’t back off. You can’t not give us what we want. We have to have this ability to innovate and differentiate, because that way we will keep our customers and we will keep this organization alive.”

That applies equally to the public and private sectors. The public sector organizations have this mandate of improving service, whether it’s in healthcare, insurance, tax, or whatever. So all of these commitments are being made and people have to deliver on them, albeit that the money, the IT budget behind it, is shrinking or has shrunk.

The leaders must understand what drives their company. Understand the values, the differentiation, and the innovations that you want and put your money on those and then find a way of dramatically reducing the amount of money you spend on the contextual stuff, which is pure productivity.

Woods: … Decentralizing the architecture improves your efficiency and your redundancy. There is much more opportunity for building a solid, maintainable architecture than there would be if you kept a sort of monolithic approach that’s typical on the mainframe.

… The problem is sometimes not nearly as big as it seems. If you look at the analogy of the clone codes that we find, and all the different areas that we can look at the code and say that it may not be as relevant to a transformation process as you think it is.

The subject matter experts and the stakeholders very slowly start to understand that this is actually possible. It’s not as big as we thought.

I do this presentation called “Honey I Shrunk the Mainframe.” If you start looking at these different aspects between the clone code and what I call the asymmetrical transformation from handwritten code to model driven architecture, you start looking at these different things. You start really seeing it.

We see this, when we go in to do the workshops. The subject matter experts and the stakeholders very slowly start to understand that this is actually possible. It’s not as big as we thought. There are ways to transform it that we didn’t realize, and we can do this incrementally. We don’t have to do it all at once.

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

October 25th, 2009

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

Posted by Dana Gardner @ 10:44 am

Categories: Application Lifecycle Management, Cloud computing, Developer Tools, Enterprise Java, Government, HP, Hardware Infrastructure, Home, IBM, IT Management, IT Service Management, ITIL, Java, Linux, Open Source, Oracle, Podcasts, SOA, SOA Governance, SOA architect, SaaS, Software Development, Software Infrastructure, System Z, VMware, Virtualization, database, datacenters, governance, mainframe, management

Tags: Legacy Application, Transformation, ROI, End-user Productivity, Podcasts, Roi/Tco, Strategy, Internet, Finance, Managerial Accounting

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.

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.

October 19th, 2009

Speaking of SOA: Are services nouns or verbs?

Posted by Dana Gardner @ 11:09 am

Categories: .NET, Agile Development, Application Lifecycle Management, Cloud computing, Developer Tools, Eclipse, Enterprise Java, IT Service Management, SOA, SOA Governance, SOA architect, Software Development, Software Infrastructure, Web Services, governance, management

Tags: Operation, ZapThink LLC, Policy, SOA, Simple Object Access Protocol, Object-oriented, Service-Oriented Architecture (SOA), Web Services, SOAP, Ooa/Ood/Oop

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.


October 16th, 2009

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

Posted by Dana Gardner @ 8:29 am

Categories: Agile Development, Amazon, Apple, Application Lifecycle Management, BI, Cisco, Cloud computing, Enterprise 2.0, Enterprise Java, Google, HP, IT Management, IT Service Management, ITIL, Microsoft, Open Source, Oracle, SOA, SOA Governance, SOA architect, SaaS, Security, Software Development, Software Infrastructure, VMware, Virtualization, Web Services, Web Technology, business intelligence, convergence, datacenters, governance, iPhone, management

Tags: Forrester Research Inc., Operational Planning, Pricing, Business Intelligence, Tools & Techniques, Strategy, Business Operations, Marketing, Enterprise Software, Software

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
  • Restructured IT services platforms
  • 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 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-o-hones 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.

October 14th, 2009

CEO interview: Workday's Aneel Bhusri on advancing SaaS and cloud models for improved ERP

Posted by Dana Gardner @ 10:57 am

Categories: Agile Development, Application Lifecycle Management, Cloud computing, Google, Government, IT Service Management, ITIL, Microsoft, Oracle, Podcasts, SAP, SaaS, Software Development, Software Infrastructure, Web Services, Web Technology, datacenters, iPhone, mainframe, management

Tags: PeopleSoft Inc., Software-as-a-service, ERP, Workday, BriefingsDirect Podcast, Enterprise Resource Planning (ERP), Software As A Service (SaaS), Managed Hosting, Cloud Computing, Enterprise Software

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

The latest BriefingsDirect podcast is an executive interview with a software-as-a-service (SaaS) upstart Workday, a human capital management (HCM), financial management, payroll, worker spend management, and workday benefits network provider.

I had the pleasure to recently sit down with Workday’s co-founder and co-CEO, Aneel Bhusri, who is responsible for the company’s overall strategy and day-to-day operations.

Bhusri, who also helped bring PeopleSoft to huge success, explains how Workday is raising the bar on employee life-cycle productivity by lowering IT costs through the SaaS model for full enterprise resource planning (ERP).

More than that, Workday is also demonstrating what I consider a roadmap to the future advantages in cloud computing. The interview is conducted by me, BriefingsDirect’s Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:

Bhusri: We’re very similar to PeopleSoft in some areas, and in other areas, quite different. We have the same culture — focused on employees first and customers second. We focus on integrity. We focus on innovation. We brought that same culture to Workday, and our customers are very happy.

The pedigree of the team starts with my co-founder, Dave Duffield. He’s an icon in the software industry. He’s known for high integrity, innovation, and customer service. Many of us, like me, have been with him for 17 years now and we share that vision and that culture with him. We have set out to build the next great software company.

Much like PeopleSoft, we are taking advantage of a technology shift. PeopleSoft benefited from the shift from mainframe to client-server. When Workday started, people weren’t as focused on how big the shift was from client-server or on-premise computing to what is now called cloud computing or, back then, SaaS.

It now seems like it’s even bigger than the shift from mainframe to client-server. This is a massive shift and you see it all across. That’s the big difference. We are obviously leveraging a very different technology base.

The thing that Dave and I both took away from PeopleSoft is that you have to stay on top of innovation, and that’s what Workday is doing. We are innovating where the large ERP vendors have stopped.

One of the reasons why the margins are so high for the [legacy ERP vendors] is that they are at the tail end of the technology life cycle. They are not really innovating.

… One of the reasons why the margins are so high for the [legacy ERP vendors] is that they are at the tail end of the technology life cycle. They are not really innovating. They are collecting maintenance payments. We all know that maintenance is very, very profitable. Well, when you start in a new technology, it’s mostly investing. Usually, when the profitability rates get that high, it means that there is a new technology around the corner that will start cutting into those profitability rates.

… ERP is now 15 years old and just needs to be rewritten. The world has changed so dramatically since the original ERPs were written.

Back then, companies were thinking about being global. Now, they are global. People were not even thinking about the Internet, and now the Internet exists. That was before Sarbanes-Oxley and before the emergence of the iPhone and BlackBerry. All these things pile together to say that it’s time to go back and rewrite core ERP. It’s no longer valid in today’s world.

… These last nine months have been challenging for everyone. We, as a system-of-record vendor, saw fewer projects out there. At the same time, because of our new model and the cost benefits of the SaaS solutions, we were probably more relevant than we might have been without the economic downturn.

… As the Workday system has gotten more robust, we’ve really focused on the Fortune 1000 companies, our biggest being Flextronics. Those large, complex organizations with global requirements have a great opportunity for cost savings.

When you add it altogether . . . it averages out consistently to about a 50 percent cost saving over a five-year period.

We had companies that were planning on implementing the traditional legacy systems, but could not afford it. A great example is Sony Pictures Entertainment. They already own the licenses to the SAP HR system, and yet, after careful consideration, determined they didn’t have the budget to implement it.

… They will be live in five months, and they will get the benefit of about a 50 percent cost savings, if not more. They basically quoted it as one-half the time at one-third the cost.

… When you add it altogether, really do it on an apples-to-apples basis, and look at what we have taken over for the customers, it averages out consistently to about a 50 percent cost saving over a five-year period.

… The data we have now is not theoretical. It’s now based on 60 of our 100-plus customers. Being in production, we have been able to go back and monitor it. The good news about our cost is that it’s all-in-one subscription cost, so we know exactly what the costs were for running the Workday system.

… [Many customers] decided that they were not going to take the major upgrade from one of those ERP vendors. A major upgrade is much like a new implementation and it’s cost prohibitive.

With our focus on continuing innovation, they are not stuck in time. Every customer gets upgraded every four months to the most current version of the system. So as we are innovating, they are all taking the advantage of that innovation, whether it’s in usability, functionality, or a new business model.

I like to think about it as building at web speed, and that’s how Google, Amazon, and eBay think about it. New features come out very quickly. There are no old versions of Amazon and eBay that they have to worry about supporting. It’s one system for all users. We’re able to leverage those same principles that they are and bring out capabilities very quickly, so a customer can identify something that’s important to them.

If you can get your administrative applications, your non-mission critical applications . . . delivered from a vendor . . . why not focus your resources on the core enterprise apps you have?

… I think we are a lot like Salesforce. Dave and I have a very good relationship with Marc Benioff. They’re focused on CRM, and we’re focused on ERP. I think the big difference is that they are focused on becoming a platform vendor, and we are really very focused on staying as an application vendor.

… If you can get your administrative applications, your non-mission critical applications — CRM, HR, payroll, and accounting — delivered from a vendor, and you can manage them to service-level agreements (SLAs), why not focus your resources on the core enterprise apps you have?

More and more CIOs are getting that. It does free up data-center space. It also frees up human resources and IT to focus in on what’s core to their business. HR and accounting don’t have to be specialized in running that system. They have to know HR and accounting, but they don’t have to be specialized in running those systems.

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

October 5th, 2009

HP roadmap dramatically reduces energy consumption across data centers

Posted by Dana Gardner @ 6:25 pm

Categories: Application Lifecycle Management, Cloud computing, HP, Hardware Infrastructure, IT Management, IT Service Management, ITIL, Podcasts, SOA Governance, Software Development, Software Infrastructure, VMware, Virtualization, database, datacenters, management

Tags: Data Center, Hewlett-Packard Co., Server, Data Centers, Storage, Hardware, Data Management, Dana Gardner

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

Gain more insights into data center transformation best practices by downloading free whitepapers at http://www.hp.com/go/dctpodcastwhitepapers.


P
roducing meaningful, long-term energy savings in IT operations depends on a strategic planning and execution process.

The goal is to seek out long-term gains from prudent, short-term investments, whenever possible. It makes little sense to invest piecemeal in areas that offer poor returns, when a careful cost-benefit analysis for each specific enterprise can identify the true wellsprings of IT energy conservation.

The latest BriefingsDirect podcast discussion therefore targets significantly reducing energy consumption across data centers strategically. In it we examine four major areas that result in the most energy policy bang for the buck — virtualization, application modernization, data-center infrastructure best practices, and properly planning and building out new data-center facilities.

By focusing on these major areas, but with a strict appreciation of the current and preceding IT patterns and specific requirements for each data center, real energy savings — and productivity gains — are in the offing.

To help learn more about significantly reducing energy consumption across data centers, we welcome two experts from HP: John Bennett, worldwide director, Data Center Transformation Solutions , and Ian Jagger, worldwide marketing manager for Data Center Services. The discussion is moderated by me, BriefingsDirect’s Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:

Bennett: We, as an industry, are full of advice around best practices for what people should be taking a look at. We provide these wonderful lists of things that they should pay attention to — things like hot and cold aisles, running your data center hotter, and modernizing your infrastructure, consolidating it, virtualizing it, and things of that ilk.

The mistakes that customers do make is that they have this laundry list and, without any further insight into what will matter the most to them, they start implementing these things.

The real opportunity is to take a step back and assess the return from any one of these individual best practices. Which one should I do first and why? What’s the technology case and what’s the business case for them? That’s an area that people seem to really struggle with.

… We know very well that modern infrastructure, modern servers, modern storage, and modern networking items are much more energy efficient than their predecessors from even two or three years ago.

If we look at the total energy picture and the infrastructure itself — in particular, the server and storage environment — one of the fundamental objectives for virtualization is to dramatically increase the utilization of the assets you have.

With x86 servers, we see utilization rates typically in the 10 percent range. So, while there are a lot interesting benefits that come from virtualization from an energy efficiency point of view, we’re basically eliminating the need for a lot of server units by making much better use of a smaller number of units.

So, consolidation and modernization, which reduces the number of units you have, and then multiplying that with virtualization, can result in significant decreases in server and storage-unit counts, which goes a long way toward affecting energy consumption from an infrastructure point of view.

That can be augmented, by the way, by doing application modernization, so you can eliminate legacy systems and infrastructure and move some of those services to a shared infrastructure as well.

We’re talking about collapsing infrastructure requirements by factors of 5, 6, or 10. You’re going from 10 or 20 old servers to perhaps a couple of servers running much more efficiently. And, with modernization at play, you can actually increase that multiplication.

These are very significant from a server point of view on the storage side. You’re eliminating the need for sparsely used dedicated storage and moving to a shared, or virtualized storage environment, with the same kind of cost saving ratios at play here. So, it’s a profound impact in the infrastructure environment.

Jagger: Going back to the original point that John made, we have had the tendency in the past to look at cooling or energy efficiency coming from the technology side of the business and the industry. More recently, thankfully, we are tending to look at that in a more converged view between IT technology, the facility itself, and the interplay between the two.

… Each customer has a different situation from the next, depending on how the infrastructure is laid out, the age of the data center, and even the climatic location of the data center. All of these have enormous impact on the customer’s individual situation.

… If we’re looking, for example, at the situation where a customer needs a new data center, then it makes sense for that customer to look at all the cases put together — application modernization, virtualization, and also data center design itself.

Here is where it all stands to converge from an energy perspective. Data centers are expensive things to build, without doubt. Everyone recognizes that and everybody looks at ways not to build a new data center. But, the point is that a data center is there to run applications that drive business value for the company itself.

What we don’t do a good job of is understanding those applications in the application catalog and the relative importance of each in terms of priority and availability. What we tend to do is treat them all with the same level of availability. That is just inherent in terms of how the industry has grown up in the last 20-30 years or so. Availability is king. Well, energy has challenged that kingship if you like, and so it is open to question.

. . . Converging the facility design with application modernization, takes millions and millions of dollars of data center construction costs, and of course the ongoing operating costs derived from burning energy to cool it at the end of the day.

Now, you could look at designing a facility, where you have within the facility specific PODs (groups of compute resources) that would be designed according to the application catalog’s availability and priority requirements, tone down the tooling infrastructure that is responsible for those particular areas, and just retain specific PODs for those that do require the highest levels of availability.

Just by doing that, by converging the facility design with application modernization, takes millions and millions of dollars of data center construction costs, and of course the ongoing operating costs derived from burning energy to cool it at the end of the day.

… One of the smartest things you can actually do as a business, as an IT manager, is to actually go and talk to your utility company and ask them what rebates are available for energy savings. They typically will offer you ways of addressing how you can improve your energy efficiency within the data center.

That is a great starting point, where your energy becomes measurable. Taking an action on reducing your energy, not just hits your operating cost, but actually allows you to get rebates from your energy company at the same time. It’s a no-brainer.

Bennett: What we are advising customers to do is take a more complete view of the resources and assets that go into delivering business services to the company.

It’s not just the applications and the portfolio. … It’s the data center facilities themselves and how they are optimized for this purpose — both from a data center perspective and from the facility-as-a-building perspective.

In considering them comprehensively in working with the facilities team, as well as the IT teams, you can actually deliver a lot of incremental value — and a lot of significant savings to the organization.

… For customers who are very explicitly concerned about energy and how to reduce their energy cost and energy consumption, we have an Energy Analysis Assessment service. It’s a great way to get started to determine which of the best practices will have the highest impact on you personally, and to allow you to do the cherry-picking.

For customers who are looking at things a little more comprehensively, energy analysis and energy efficiency are two aspects of a data-center transformation process. We have a data center transformation workshop.

Jagger: The premise here is to understand possible savings or the possible efficiency available to you through forensic analysis and modeling. That has got to be the starting point, and then understanding the costs of building that efficiency.

Then, you need a plan that shows those costs and savings and the priorities in terms of structure and infrastructure, have that work in a converged way with IT, and of course the payback on the investment that’s required to build it in the first place.

Gain more insights into data center transformation best practices by downloading free whitepapers at http://www.hp.com/go/dctpodcastwhitepapers.

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

September 21st, 2009

Process isomorphism: The critical link between SOA and BPM

Posted by Dana Gardner @ 10:33 am

Categories: .NET, Application Lifecycle Management, Cloud computing, HP, IBM, IT Management, IT Service Management, ITIL, Microsoft, Progress Software, SOA, SOA Governance, SOA architect, Software Development, Software Infrastructure, Virtualization, Web Services, governance, management

Tags: Process, Business Process, ZapThink LLC, BPM, SOA, Logic, Composition, Isomorphism, Service-Oriented Architecture (SOA), Operational Planning

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

Take the BriefingsDirect middleware/ESB survey now.

By Jason Bloomberg

ZapThink has long championed the close relationship between business process management (BPM) projects and service-oriented architecture (SOA) initiatives. As anyone who has been through our Licensed ZapThink Architect Bootcamp can attest, we have a process-centric view of SOA, where the point to building loosely coupled business services is to support metadata-driven compositions that implement business processes, what we call service-oriented business applications, or SOBAs, for want of a better term.

Nevertheless, there is still confusion on this point, among enterprise practitioners who see BPM as a business effort and SOA as technology-centric, among vendors who see them as separate products in separate markets, and even among pundits who see Services as supporting business functions but not business processes.

On the other hand, there are plenty of enterprise architects who do see the connection between these two initiatives, and who have pulled them together into “BPM enabled by SOA” efforts. This synergy, however, is not automatic, and requires some hard work both among the people focusing on optimizing business processes to better meet changing business needs as well as the team looking to build composable business services that support the business agility and business empowerment drivers for their SOA initiatives.

ZapThink has worked with many such organizations, and over time a distinct best practice pattern has emerged, one that is both fundamental as well as subtle, and as a result, has fallen through the cracks of compendia of SOA patterns: the Process Isomorphism pattern. Understanding this pattern and how to apply it can help organizations pull their BPM and SOA efforts together, and even more importantly, improve the alignment of their SOA initiatives with core business drivers.

What is Process Isomorphism?

An isomorphism is a mathematical concept that expresses a relationship between two concepts that are structurally identical but may differ in their respective implementations. A very simple example would be two tic-tac-toe games, one with the traditional X’s and O’s, and the other with, say, red dots and blue dots. The game board and the rules are the same, in spite of the difference in symbols the players use to play the games. If two particular games follow the same sequence of moves, they would be isomorphic.

The term process isomorphism usually refers to two processes that are structurally identical, typically between two companies in the same industry. For example, if the order-to-cash process is structurally identical between companies A and B, that is, the same steps in the same order with the same process logic, those processes would be isomorphic, even if the two companies had differences in their underlying technical implementations of the respective processes.

We’re using the term differently here, however. Process isomorphism in the SOA context is an isomorphism between a process on the one hand, and the SOBA that implements it on the other. In other words, if you were to model a business process, and as a separate exercise, model the composition of services that implements that process, where those two models have the same structure, then they would be isomorphic.

One conversation that helped crystallize this notion was with John Zachman, who was explaining some of the changes he has recently made to his seminal Zachman Framework. He has renamed Row 3, which had been the System Model row, to the System Logic row. People were confusing the System Model with the physical representation of the system, which resides one row down. Our discussion of process isomorphism is essentially a design practice that relates these two rows of Column 2, the How column. In essence, the process logic model is one level above the service composition model that implements the process logic. The process isomorphism pattern states that these two models should be isomorphic.

Process Isomorphism in Practice

We’ve been using a wonderful example of Process Isomorphism on our LZA Course for a few years now, courtesy of British Petroleum (BP), who presented at our Practical SOA event in February, 2008 (more about our upcoming Practical SOA event). The presentation focused on how process decomposition is the common language between business and IT efforts, and one of the examples focused on the Well Work Performance process, one of thousands of processes in their oil drilling line of business:

BP’s Well Work Performance Process

The Description column in the chart above reflects the four main subprocesses that make up this process. The Sub-Task columns represent individual sub-tasks, or steps in the process. Finally, the Supporting Service Name column indicates the Business Service that implements the corresponding sub-task. The fact that there is a one-to-one correspondence between sub-tasks and supporting Services, combined with the implied correspondence between the process logic and the composition logic, illustrates Process Isomorphism. In this simple example, the process logic is a simple linear sequence, but if the logic were more complex, say with branching and error conditions, then the process would exhibit isomorphism if the composition logic continued to reflect the process logic.

It is important to point out that the one-to-one correspondence between process sub-tasks and supporting Services is by no means a sure thing, and in practice, many organizations fail to design their compositions with such a correspondence. Frequently, the issue is that the SOA effort is excessively bottom-up, where architects specify services based upon existing capabilities. Such bottom-up approaches typically yield services that don’t match up with process requirements. Equally common are BPM efforts that are excessively top-down, in that they seek to optimize processes without considering the right level of detail for those processes to enable services to implement steps in the processes. Only by taking an iterative approach where each iteration combines top-down and bottom-up design is an organization likely to achieve Process Isomorphism.

The Process Isomorphism Value Proposition


T
he essential benefit of Process Isomorphism is being able to use the process representation to represent the composition and vice-versa. While these concepts are fundamentally different, in that they live on different rows of the Zachman Framework, the isomorphism relationship allows us the luxury of considering them to be the same thing. In other words, we can discuss the composition as though it were the process, and the process as though it were the composition.

This informal equivalence gives us a variety of benefits. For example, if process steps correspond directly to services, then service reuse is more straightforward to achieve than when the correspondence between steps and services is less clear. Service reuse discussions can be cast in the context of process overlaps. If two processes share a sub-task, then the SOBAs that implement those processes will share the supporting service. In addition, the metadata representation of the composition logic, for example, a BPEL file, will represent the process logic itself. Without process isomorphism, the process logic the BPM team comes up with won’t correspond directly to the BPEL logic for the supporting composition. This disconnect can lead directly to misalignment between IT capabilities and business requirements, and also limits business agility, because a lack of clarity into the relationship between process and supporting composition can lead to unintentional tight coupling between the two.

The ZapThink Take

Perhaps the greatest benefit of Process Isomorphism, however, is that it helps to establish a common language between business and IT. The business folks can be talking about processes, and the IT folks can be talking about SOBAs, and at a certain level, they’re talking about the same thing. The architect knows they’re different concepts, of course, but conversations across the business/IT aisle no longer have to dwell on the differences.

The end result should be a better understanding of the synergies between BPM and SOA. If process specialists want to think of business services as process sub-tasks, then they can go right ahead. Similarly, if technical implementers prefer to think of business processes as being compositions of services, that’s fine too. And best of all, when the BPM team draws the process specification on one white board and the SOA team draws the composition specification on another, the two diagrams will look exactly alike. If that’s not business/IT alignment, then what is?

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

Take the BriefingsDirect middleware/ESB survey now.


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.


September 18th, 2009

Caught between peak and valley -- How CIOs survive today, while positioning for tomorrow

Posted by Dana Gardner @ 9:11 am

Categories: Agile Development, Application Lifecycle Management, Cloud computing, Enterprise 2.0, HP, Hardware Infrastructure, IT Management, IT Service Management, ITIL, Podcasts, SOA, SOA Governance, SOA architect, SaaS, Software Development, Software Infrastructure, Virtualization, convergence, datacenters, governance, management

Tags: CIO, Financial, Positioning, Financial Community, Financial Accounting, Strategy, Finance, Management, Dana Gardner

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

Are CIOs are making the right decisions and adjustments in both strategy and execution as we face a new era in IT priorities? The combination of the down economy, resetting of IT investment patterns, and the need for agile business processes, along with the arrival of some new technologies, are all combining to force CIOs to reevaluate their plans.

What should CIOs make as priorities in the short, medium, and long terms? How can they reduce total cost, while modernizing and transforming IT? What can they do to better support their business requirements? In a nutshell, how can they best prepare for the new economy?

Here to help address the pressing questions during a challenging time — and yet also a time in which opportunity and differentiation for CIOs beckons — is Lee Bonham, marketing director for CIO Agenda Programs in HP’s Technology and Solutions Group. The interview is moderated by me, Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:

Bonham: We all recognize that we’re in a tough time right now. In a sense, the challenge has become even more difficult over the past six months for CIOs and other decision-makers. Many people are having to make tough decisions about where to spend their scarce investment dollars. The demand for technology to deliver business value is still strong, and it perhaps has even increased, but the supply of funding resources for many organizations has stayed flat or even gone down.

To cope with that, CIOs have to work smarter, not harder, and have to restructure their IT spending. Looking forward, we see, again, a change in the landscape. So, people who have worked through the past six months may need to readjust now.

What that means for CIOs is they need to think about how to position themselves and how to position their organizations to be ready when growth and new opportunity starts to kick in. At the same time, there are some new technologies that CIOs and IT organizations need to think about, position, understand, and start to exploit — if they’re to gain advantage.

Organizations need to take stock of where they are and implement three strategies:

  • Standardize, optimize, and automate their technology infrastructure — to make the best use of the systems that they have installed and have available at the moment. Optimizing infrastructure can lead to some rapid financial savings and improved utilization, giving a good return on investment (ROI).
  • Prioritize — to stop doing some of the projects and programs that they’ve had on their plate and focus their resources in areas that give the best return.
  • Look at new, flexible sourcing options and new ways of financing and funding existing programs to make sure that they are not a drain on capital resources. We’ve been putting forward strategies to help in these three areas to allow our customers to remain competitive and efficient through the downturn. As I said, those needs will carry on, but there are some other challenges that will emerge in the next few months.

Growth may come in emerging markets, in new industry segments, and so on. CIOs need to look at innovation opportunities. Matching the short-term and the long-term is a real difficult question. There needs to be a standard way of measuring the financial benefit of IT investment that helps bridge that gap.

There are tools and techniques that leading CIOs have been putting in place around project prioritization and portfolio management to make sure that they are making the right choices for their investments. We’re seeing quite a difference for those organizations that are using those tools and techniques. They’re getting very significant benefits and savings.

The financial community is looking for fast return — projects that are going to deliver quick benefits. CIOs need to make sure that they represent their programs and projects in a clear financial way, much more than they have been before this period. Tools like Project and Portfolio Management (PPM) software can help define and outline those financial benefits in a way that financial analysts and CFOs can recognize.

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

September 16th, 2009

Jericho Forum aims to guide enterprises through risk mitigation landscape for cloud adoption

Posted by Dana Gardner @ 12:33 pm

Categories: .NET, Akamai, Amazon, Application Lifecycle Management, Cisco, Cloud computing, Google, IT Management, IT Service Management, ITIL, Internet, Microsoft, Podcasts, SOA, SOA Governance, SOA architect, SaaS, Software Development, Software Infrastructure, Virtualization, governance, management

Tags: Jericho Forum, Podcasts, Cloud Computing, Virtualization, Security, Internet, Hardware, Dana Gardner

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: The Open Group.

My latest podcast discussion comes from The Open Group’s 23rd Enterprise Architecture Practitioners Conference and associated 3rd Security Practitioners Conference in Toronto.

We’re talking about security in the cloud and decision-making about cloud choices for enterprises. There has been an awful lot of concern and interest in cloud and security, and they go hand in hand.

We’ll delve into some early activities among several standards groups, including the Jericho Forum. They are seeking ways to help organizations approach cloud adoption with security in mind.

Here to help on the journey toward safe cloud adoption, we’re joined by Steve Whitlock, a member of the Jericho Board of Management. The interview is conducted by me, Dana Gardner, principal analyst at Interarbor Solutions.

Here are some excerpts:

Whitlock: A lot of discussions around cloud computing get confusing, because cloud computing appears to be encompassing any service over the Internet. The Jericho Forum has developed what they call a Cloud Cube Model that looks at different axis or properties within cloud computing, issues with interoperability, where is the data, where is the service, and how is the service structured.

The Cube came with a focus on three dimensions: whether the cloud was internal

The in-source-outsource question is still relevant. That’s essentially who is doing the work and where their loyalty is.

or external, whether it’s was open or proprietary, and, originally, whether it was insourced or outsourced. … There are a couple of other dimensions to consider as well. The insource-outsource question is still relevant. That’s essentially who is doing the work and where their loyalty is.

They’ve also coupled that with the layered model that looks at hierarchical layer of cloud services, starting at the bottom with files services and moving up through development services, and then full applications.

The Jericho Forum made its name early on for de-perimeterization or the idea that barriers between you and your business partners were eroded by the level of connectivity you needed do the business. Cloud computing could be looked at the ultimate form of de-perimeterization. You no longer know even where your data is.

… Similar to SOA, the idea of direct interactive services on demand is a powerful concept. I think the cloud extends it. If you look at some of these other layers, it extends it in ways where I think services could be delivered better.

It would be nice if the cloud-computing providers had standards in this area. I don’t see them yet. I know that other organizations are concerned about those. In general, the three areas concerned with cloud computing are, first, security, which is pretty obvious. Then, standardization. If you invest a lot of intellectual capital and effort into one service and it has to be replaced by another one, can you move all that to the different service? And finally, reliability. Is it going to be there when you need it?

… There are concerns, as I mentioned before — where the data is and what is the security around the data — and I think a lot of the cloud providers have good answers. At a really crude level, the cloud providers are probably doing a better job than many of the small non-cloud providers and maybe not as good as large enterprises. I think the issue of reliability is going to come more to the front as the security questions get answered.

… It’s very important to be able to withdraw from a cloud service, if they shut down for some reason. If your business is relying them for day-to-day operations, you need to be able to move to a similar service. This means you need standards on the high level interfaces into these services. With that said, I think the economics will cause many organizations to move to clouds without looking at that carefully.

Formal relationship

The Jericho Forum is also working with the Cloud Security Alliance on their framework and papers. … It’s a very complementary [relationship]. They arose separately, but with overlapping individuals and interests. Today, there is a formal relationship. The Jericho Forum has exchanged board seats with the Cloud Security Alliance, and members of the Jericho Forum are working on several of the individual working groups in the Cloud Security Alliance, as they prepare their version 2.0 of their paper.

… In addition to the cube model, there is the layered model, and some layers are easier to outsource. For example, if it’s storage, you can just encrypt it and not rely on any external security. But, if it’s application development, you obviously can’t encrypt it because you have to be able to run code in the cloud.

I think you have to look at the parts of your business that are sensitive to needs for encryption or export protection and other areas, and see which can fit in there. So, personally identifiable information (PII) data might be an area that’s difficult to move in at the higher application level into the cloud.

I think the interest in how to protect data, no matter

It’s very important to be able to withdraw from a cloud service, if they shut down for some reason. … You need to be able to move to a similar service.

where it is, is what it really boils down to. IT systems exist to manipulate, share, and process data, and the reliance on perimeter security to protect the data hasn’t worked out, as we’ve tried to be more flexible.

We still don’t have good tools for data protection. The Jericho Forum did write a paper on the need for standards for enterprise information protection and control that would be similar to an intelligent version of rights management, for example.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: The Open Group.

Dana GardnerDana Gardner is principal analyst of Interarbor Solutions. For disclosures on Dana's industry affiliations, click here or to view his full profile click here.

Email Dana Gardner

Subscribe to BriefingsDirect via Email alerts or RSS.


Link to BriefingsDirect podcast. Subscribe to the podcast Feed. Subscribe with iTunes.


SponsoredWhite Papers, Webcasts, and Downloads

advertisement

Recent Entries

Most Popular Posts

Premier Vendor Content Whitepapers, webcasts & resources from our Power Center Sponsors
advertisement

Archives

Favorite Links

ZDNet Blogs

White Papers, Webcasts, and Downloads

SmartPlanet

  • Thought-provoking progressive ideas on diverse topics that intersect with technology, business, and life, and matter to the world at large. Visit SmartPlanet
  • More from IBM
  • Innovate your business' process model, play against the market, compete against others on our scoreboards and WIN! Try INNOV8 2.0: A BPM Simulator
  • Enabling Real-World Business Transformation through IBM Service Management Read the EMA Analyst Report
Click Here