The ITKO Blog: Service Virtualization and Application Lifecycle Optimization - CA Technologies

Perfecting IT Strategies in a Down Economy

In today's tough economy, you can't even read an article that doesn't start out: "In today's tough economy..." This one is no different. Fortunately when it comes to IT, the message does not need to be accompanied with knee-jerk cost-cutting measures.

Last month Todd Biske offered some solid advice on what to do in today's down economy in his post, "Don’t Go On an IT Diet, Change Your Behavior". Needless to say, his post remains relevant. I especially liked his comments:

“The whole point of Enterprise Architecture, SOA, and many of these other strategic IT initiatives is to allow IT to be more agile- to respond more quickly to changes in the business objectives. Guess what? We’re in the middle of a big unprecedented change in our lifetime. My guess is that the best survivors of this meltdown will be organizations that don’t go on a starvation diet, but instead simply recognize that their priorities and goals have changed and execute without significant disruption to the way they utilize IT.”

Todd also wrote that cost cutting efforts to respond to the economy should not mean that organizations drop their SOA initiatives, or other long-term initiatives, especially when most of these efforts are trying to reduce costs cost by eliminating redundancy in the enterprise. It would be ironic as these efforts are exactly what are needed today.

SOA efforts should be more closely managed and held to their ROI objectives in any economy - otherwise, they will not have a chance to create the value you expected. It may be that closer review will actually improve the number of SOA efforts that are successful, as people will be more highly motivated to get them right. There is no time for poor execution now but there is a lot of room for innovation. As Jonathan Schwartz, the Sun COO, wrote in "Innovation Loves a Crisis," now is the time to make changes that will make you most adaptive to the new economy and best positioned to come out of the downturn on top.

McKinsey also supported this strategic thinking in their report, "Leading through uncertainty": “The task of business leaders must be to overcome the paralysis that dooms any organization, and to begin shaping the future.” Transforming to SOA - not because it's "cool" but because we have real value expectations, is one way to become more flexible and cost effective at the same time.

Accompanying that, we are also sure to mention Service Virtualization as a key means of increasing the availability of SOA assets in the lifecycle, at a small fraction of the environmental cost. It is money well spent not just in terms of cost savings, but more so in coming out of a lean time with a more agile and efficiently delivering dev and test organization.

Minimize IT Outsourcing Risk with Collaborative Quality - Part One

This is the first of a four part series that summarizes the key points outlined in our paper on Minimizing IT Outsourcing Risk with Collaborative Quality. You can click on the title to get the complete white paper.

In the past ten years we have seen explosive growth in the practice of outsourcing IT functions to SIs (System Integrators) and services firms around the world. One of the fastest growing areas was the practice of outsourcing software testing to overseas teams. How as enterprise systems change from huge monolithic applications to more componentized, services-based solutions, the risk involved in outsourcing testing rises. This series looks at these risks and offers a solution.

First let’s set the stage by looking at four common IT outsourcing models:

1. Single Outsource Vendor where the buyer outsources all IT development and testing functions to a single SI partner. It offers the benefit of a single source for delivery of business applications, and one vendor to call if something goes wrong. However, it can also create high switching costs if you decide to change vendors later.
2. Outsourced Testing appears to be the easiest route if you decide to keep software development close to home. Since testing is by nature the process of “breaking” an application, many organizations find that a removed third party tester can be very valuable and impartial. This model was very easy to adopt when testing was a manual, point-and-click-on-the-screen endeavor that was best done by less costly staff. But times have changed, forcing testing offerings to evolve in sophistication.
3. Development Support. The many companies following this strategy are seeking both cost efficiency for non-differentiating development tasks, and access to developers with specialized skills needed to carry out specific tasks, such as migration between two different integration platforms that they may not have the expertise to pull off in-house.
4. Multi-Vendor is most common when development and testing activities are outsourced to different SIs. In this model, the company hopes to keep costs down, while the multiple providers keep each other "in check" to ensure project success. While you can mitigate some risks associated with a single outsource vendor, it can also be harder to manage multiple firms and get them to collaborate as efficiently.

Now let's look at the risks, as managing risk can be more important than obtaining upfront savings, if these cost reductions come back to haunt you later. After all, what good is a lower cost project if it takes 3 times as long to repair, or if your app fails in front of customers? Your outsourcing partner needs to be incented to build quality into the application, and not simply cut costs and initial project time.

This balance of quality and speed gets more complex when multiple teams are involved. While many larger companies have a multi-vendor strategy of procuring IT services, the more companies and teams that are involved in a project, the more opportunities there are for the information sharing and collaboration to break down.

What is needed is greater team accountability for shared deliverables all the way across the software lifecycle, which includes visibility into problems early, versus later in the deployment where they become significantly more costly. There is also the risk generated by dependencies on unavailable or inaccessible systems. Interdependent teams working together can be constrained by limited access to live applications and components that are not yet completed or available for testing. We see this issue often in the field as reported in our series.

When there is increased contention for shared resources, agility suffers as teams are forced to queue up for access, introducing scheduling delays and project risks. In some cases, teams may attempt to maintain their own test environments by replicating the components they need in a testing lab or custom test harness.

These team-to-team constraints on environments can become very costly to manage, requiring a high level of configuration, licensing costs and maintenance to keep current, even if it is running on virtualized hardware (which also has incremental licensing costs). And of course, some sensitive systems such as ERP mainframes are simply too big and have too much overhead to be replicated by conventional hardware virtualization means. In our next post in this series, we start to look at ways to meet these challenges and make more effective use of IT outsourcing.

ebizQ Discussion on SOA & Cloud Computing - Everyone's got a point...

The eBizQ site recently hosted a discussion is based on JP Morgenthal's feature article, Differing Views on SOA & Cloud Computing, and the question, which seemed to cause a bit of disagreement between the old "gray hair" and new "newbie" schools of IT, is: SOA & Cloud Computing new and unique or a continuation of the same old stuff?

Occasionally you come across a topic like this that touches off a flood of responses from the community. There are a range of insights from a "who's who" of SOA and IT pundits on this particular topic worth looking at on the ebizQ discussion site: SOA & Cloud Computing: New & Unique or Continuation of the Same Old Stuff?

Here was my response:

The future risk of the cloud is the current risk of SOA. I agree with the above statements about the hype factor of cloud computing, however there's still one more challenge that both strategies will share -- dependency. In SOA engagements, we encouraged the importance of good architecture and governance, but often it was just too easy for companies to hook up a couple web services to a legacy system for a quick ROI.

Dependency didn't rear its ugly head in SOA until the services started to be used by multiple customers, each with their own needs, and then those services were connected with the services of business partners, and used in a variety of unintended ways. A lack of access to dependent services and systems throughout the development lifecycle created a constraint on the agility we expected from SOA.

Similarly, the true cost and complexity of using cloud-based solutions will become evident only at the point when companies rely on them for critical needs. The low cost of entry of the Cloud's easy provisioning and pay-as-you-use can end up costing more than expected once the solution reaches business volume. If I pay-per-use for a cloud-based solution, I am establishing recurring costs, and increasing dependencies in my testing, development and release of new functionality that need to be addressed. Hopefully this shared concern of dependency will encourage enterprises not to sacrifice good architecture, governance, and virtualization practices for short term ROI gains.

We see many companies getting past the hype of SOA to generate real value today by applying the approach with more discipline, and many of the same lessons will apply to cloud computing.

Field Reports on SOA Success - Part Six: Major Enterprise Software Firm

In life, there are some good surprises (birthdays, hearing a great new song, meeting that special someone), but in enterprise software, not so much. This sixth example in our stories from the field is about a major enterprise software firm.

This firm decided to move much of the sales of their software upgrades and maintenance contracts to a web portal, where clients could just buy and download the updates they needed. Previously the sales force would not have to get involved with contacting each client and conducting manual orders on routine stuff, which wasted time for both parties. Many clients had open POs so they could just add on these incremental purchases. This was to be a win for both sides.

To set this up, they needed to access the customer data and their software inventory. They could then make suggestions about what additions might be needed, offer the ability to instantly purchase, and download. They did manual testing of the system UI, and thorough unit testing of the software. Everything seemed okay for rollout.

However, as they discovered three months after the launch, there was a problem with the all-important middle step. The system was supposed to push the order into the enterprise invoicing system, SAP in this case. Then the client would be billed.

Ninety days after launch, the guy responsible for the SAP transaction system asked if they had started this new system since no orders had entered into the system of record. To their embarrassment, the clients were getting their software downloads, but their invoices were not getting recorded.

It seems another group implemented a policy so that each account had a password change every 90 days. These changes occurred between the application test time and the launch time. So fulfilled upgrade orders were getting logged as bad data, and then flushed on a regular basis. The clients were not complaining because they were getting the software, and likely did not mind that the invoicing appeared slow.

The firm brought us in to do end-to-end business process testing to make sure that all steps in the process worked on sample cases. We tested not just at the web ordering UI layer, but followed that transaction through the app server, ESBs, CORBA and all the way to confirming that it made it into the system of record. We call this practice “invoke and verify.”

After software was downloaded, LISA made sure the invoice was processed for that specific download, and the team quickly rooted out the “changed password” culprit that was causing orders to get routed incorrectly from within the ESB layer. This validation was also done on a continuous basis to make sure any new changes did not disrupt the flow. Now all steps in the process work, and the original goals of better customer service at lower cost -- without the unwelcome surprises -- were achieved.

You can find the complete case details here.

Field Reports on SOA Success - Part Five: Major Airlines

We’ve talked a lot about how ensuring quality is a big challenge for complex SOA and enterprise software environments. But there is a bigger-picture risk that can drive any project past deadline and over budget: constrained and costly access to necessary systems and data throughout the development and testing lifecycle. This fifth example is about a major airline.

Like many companies, they faced constraints in their testing environment. In the airline industry, this is magnified, as all carriers have to make use of third party reservation systems. The billing for this access runs just like cell phone billing (but on a much bigger pricing scale!), with a set limit, followed by overage charges. Anything over the limit can get very expensive. In addition, the access itself is not cheap to begin with.

This airline wanted to expand their testing lab environments from four to nine. However, given the transaction fees I just described, and the associated hardware cots, this change would run into millions of dollars of extra costs on an ongoing annual basis. In addition to the extra transaction costs, the airline would have to purchase more hardware. Since you cannot just deal with airline and customer data over the public web for very real security purposes, they needed to provision special gateways and data circuits to interact with the third party source.

However, this was just the beginning of the problems they faced. Travel data is very complex and changing. There are weather delays, fare changes, rewards programs, partner systems, flight operation systems, and so on. To build applications, you need access to stable customer and flight data scenarios for testing and validation.

The airline found that when they ran regression tests, about 10% of the test cases failed. The failures were not mostly due to bad software, but data volatility. They had to find a way overcome a huge number of false negatives due to bad test data. Teams would often waste half their day chasing down these errors. Increasing the number of test labs by over 100% would only compound these data troubles.

Introducing a strategy that covered both automated testing and Service Virtualization addressed these issues, so we brought LISA to bear and demonstrated how to virtualize these kinds of services that are prohibitively costly and complex to replicate using conventional means.

First, they eliminated the need to incur almost all the transaction costs to the third party system by accurately simulating the required data as virtual services for development and test purposes.

This also took the additional hardware costs for gateways and data circuits out of the equation by reducing infrastructure needs and virtualizing any new infrastructure requirements. These hard dollar cost savings more than covered their investment in automated testing.

There was more, as the cycle of false negatives due to bad test data was broken, as stable test data could be provided. This may prove to be the largest source of saving overall. Now application development could proceed at a much faster clip, helping the airline generate customer benefits and revenue from the new application much quicker, and reducing development costs.

They are also planning to make use of the automated testing system and the data it generates to streamline their training programs and make them accessible on a local basis, reducing the travel expenses associated with getting their employees flying on the new systems they develop.

You can find the complete case study here.

New Outsourced IT Paper - Collaborative Quality to Minimize Risk

Though we are in the testing and virtualization business, over the last 5 years we have had a lot of requests from customers for our advice about working with one or more outsourcing firms. Since we have encountered virtually every kind of working arrangement in our engagements, we do have some experience encountering both successful - and unsuccessful - teams comprised of multiple services partners.

Given the current market conditions for IT outsourcing, it seems like there is more uncertainty than ever in this realm. Outsourcing is still a must-do activity for at least some of any large enterprise IT budget.

For the most part we've kept our advice to the realm of working with our SI partners - as part of working with joint end customers, we need to cover how to better collaborate on quality, validate that business requirements like accuracy and performance benchmarks are met, and improve agility to deliver new features ahead of schedule.

There are many up-front aspects of properly selecting, negotiating contracts and defining requirements that will make or break a project - too much to cover here - but in our experience once the partners are selected, what defines the back-end of delivering a successful project?

The number one post-agreement issue we've found when companies have deployment issues and cost overruns in working with services firms, is that partners must be rewarded not just on delivery, but delivering with quality. We're not talking about simply handing down a set of requirements and enforcing them. Good collaboration is a two-way street - both the consumer and provider of services must be responsible for defining and delivering things that are tested, and testable.

Anyway, we wrote what we think is a pretty good primer on the topic - you can get the new paper here: "iTKO Whitepaper : Minimize IT Outsourcing Risk with Collaborative Quality" - http://www.itko.com/site/resources/collaborativequality.jsp. We can't tell you who to work with, but we can provide some advice we've seen on what works!

We'll be posting further thoughts on collaboration between multiple on-shore and offshore teams here - your thoughts and questions on the topic are welcome.

Guide to Service Virtualization in Enterprise Application Development - Part Six: Complete Strategy with Service Virtualization

This is the last post in our six-part series on Service Virtualization in Enterprise Application Development. The series covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle.

The complete white paper can be downloaded at Service Virtualization in Enterprise Application Development. In this post we look at a reference architecture when service architecture is added. Now we can finish solving the problems we encountered in the middle tier. We can create virtual models, modify the models to suit our needs, and enable that parallel development that we were lacking in the previous picture.

Once services are virtualized, and not just hardware, we are good to go for parallel development. Below is a diagram of the architecture:

In addition to virtual hardware, in the back end, we can take those constrained services and system resources we couldn't replicate via hardware virtualization, and make them 24/7 accessible. We can take things that had capacity constraints, for example the performance lab that could only do 10 TPS against the back-end systems, and virtualize it to allow hundreds or thousands of transactions.

I also get data consistency. I can drive the specific data scenarios that I want. I can get predictable, stable data across a variety of systems – even the systems that I do not own and control, and that’s crucial for any distributed system.

And finally, I can desensitize my sensitive systems -- take away those security constraints. The process is very much the same for hardware virtualization or service virtualization. When I virtualize a piece of hardware, I take an image of the disk. In a virtual service, you image the behavior of a particular service. You construct the virtual service from that behavior, and then you deploy it to a virtual service environment. Same steps, but different tools, and different outcomes based on the type of virtualization you are doing.

In summary, you can completely isolate IT from physical constraints by using Service Virtualization. We invite you to explore how this new strategy can deliver the cost savings and agility you expect across the lifecycle of your entire software infrastructure.

That wraps up our overview of Service Virtualization. We believe there is a huge amount of untapped value to be gained from virtualizing the behaviors of the most constrained and changing elements of business IT.

Here are the first five posts in this series. 

Guide to Service Virtualization in Enterprise Application Development – Part One of Six

Guide to Service Virtualization in Enterprise Application Development – Part Two: Hardware Virtualization

Guide to Service Virtualization in Enterprise Application Development - Part Three: Challenges of Access

Guide to Service Virtualization in Enterprise Application Development - Part Four: When No Virtualization is in Use

Guide to Service Virtualization in Enterprise Application Development - Part Five: Leveraging Hardware Virtualization

Guide to Service Virtualization in Enterprise Application Development - Part Five: Leveraging Hardware Virtualization

This is the fifth post in our six part series on, Service Virtualization in Enterprise Application Development. The series covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle. The complete white paper can be downloaded at Service Virtualization in Enterprise Application Development.

In this post, we look at a reference architecture when hardware virtualization is added to the standard architecture presented in my last post. We need to explain this step, because while virtualization at the hardware/OS level is valuable, it is only one form of virtualization for enterprise IT.

Below is a diagram of the architecture.
The market’s concept of hardware virtualization is worth applying, because it’s a good thing and it’s going to get us some value out of the box -- mostly in the middle tier. But there are still issues.
Hardware virtualization gives you the concept of server proliferation (where everybody gets their own server) but it doesn’t require physical assets to do it. This can reduce IT hardware acquisition and support costs significantly.

However, beyond the boxes, we still have difficulties with parallel application development. Realizing that Service2 is not ready for my application to use (e.g., the database in our example above), even running virtualized hardware won’t help me until the development team implements their changes. And unfortunately, I haven’t done anything to alleviate our constraints on accessing the back-end systems; possibly I have made things worse.

Because I still have access issues on the mainframe, I still have capacity constraints throughout development, testing and integration. I still have costly access on the SaaS side, and I still have an insane amount of data volatility, which makes it hard for my team to stabilize the application against the rest of the environment.

Of course, I may also have security concerns when sharing a process among teams, especially when they are distributed across departments or companies. Don't get me wrong -- preventing server proliferation in the datacenter is a good thing, but the largest, most complex systems are not meaningfully affected, and this is still why we need to stay at it and complete our virtualization strategy. In the next post, I will cover what happens when you add service virtualization to the architecture to complete the strategy.

Guide to Service Virtualization in Enterprise Application Development - Part Four: When No Virtualization is in Use

This is the fourth post in our six part series on, Service Virtualization in Enterprise Application Development. The series covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle. The complete white paper can be down loaded at Service Virtualization in Enterprise Application Development.

In this post we look at a reference architecture when no virtualization is in use to set the stage for adding hardware virtualization and then service virtualization. Below is a diagram of the architecture.
 

This is a simplified but typical application that we see all the time in our customer base. In this case applications have access to a middle-tier set of services, which are built into some kind of application server, integration layer, etc. Those services very frequently make calls out to legacy mainframe systems and third-party hosted applications.

There are lots of challenges here without any virtualization in place:

• Server proliferation in the middle tier to support multiple teams & workflows
• Lots of lost productivity while I wait for things like Service2 (above) to be developed
• Increased cost from third party systems because every time I access that SaaS-based solution or that hosted application it’s costing me money
• Increased risk of production issues because of all these things, including the fact that I can’t do as much repeatable testing because of data volatility.

In the next post, I will cover what happens when you add hardware virtualization to the architecture.

Guide to Service Virtualization in Enterprise Application Development - Part Three: Challenges of Access

This is the third post in our six part series on Service Virtualization in Enterprise Application Development. The series covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle.

The complete white paper on Service Virtualization in Enterprise Application Development can be downloaded from itko.com.

In this post, we move from hardware virtualization approaches to the service virtualization concept. Taking the concept of virtualization all the way into the service interactions and behaviors of my interconnected systems opens up new possibilities. When assets make the migration from the real world into the virtual world, they lose their constraints. I can control their behavior, I can control their capacity, their access, and I can constrain them in the ways that I want – not the ways that the real world imposes upon me. This is exactly the technique this paper covers. See an example below.
Let’s look at an example. First, the current physical environment is shown below. This presents several challenges.
 
Access to a mainframe: The trouble here is that because I’m not the only team in the environment, there are dozens of other project teams; therefore I have very infrequent access to the mainframe.
Access to a database: Another other team owns a database that we access. This database already exists; we even have access to it in a development lab, but we need new stored procedures in that database schema. It will take some 3 or 4 months of negotiating and design work to produce those stored procedures.
Access to the web service: There is a legacy system already deployed, and we’ve decided that as an architectural mandate, we are going to use web services to get at the legacy functionality; which is great — except that the web service doesn’t actually exist yet – we’re still shopping the contract so access is months away. All of the above are very real world constraints — these are nothing that we haven’t heard dozens of times from our customers. So let’s see what service virtualization can do to remove these constraints. We will describe the diagram below form the bottom up.

For mainframe access, build a model of the behavior and then host it as a virtual service in a virtual service environment. For database access, construct a model from the database and make changes as needed within minutes. For web access, construct a virtual service from a WSDL, from SOAP documents, from XML samples: whatever you can give the Virtualization team. Now I will go into these concepts in more detail in the next three posts. In the next post, I will cover reference architectures, starting with Stage One, in which no virtualization in use.

Guide to Service Virtualization in Enterprise Application Development – Part Two: Hardware Virtualization

This is the second post in our six part series on, Service Virtualization in Enterprise Application Development. The series covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle. Each post will summarize the key points within a section of the paper. The complete white paper can be downloaded at "Service Virtualization in Enterprise Application Development."

In this post we look at hardware virtualization, how it works, and why it is not a complete strategy. Most current forms of virtualization in IT could be described as hardware virtualization and they provide the three benefits we covered in the last post. Hardware virtualization creates simulators of hardware behavior, but they are actually intelligent proxies to the physical world. These proxies have the ability to negotiate with the virtual environment in which they are deployed, so they do not require exclusive access to the hardware they represent offering more flexibility.

Hardware virtualization has generated a lot of buzz for immediately realized cost savings. In most cases tools image the existing physical asset by cloning the hard disk contents. From this image, the tool constructs a virtual machine that can be put to use.

However, stopping here is not a complete strategy. First, there are many systems that simply cannot be imaged as the hardware virtualization process above defines. Examples include: Systems not on Intel-class servers like mainframes, externally hosted partner services, SaaS, cloud-based systems, and systems that are under a high degree of change. These assets are often the most mission-critical and the most costly to provide access and increased capacity.

In addition, you cannot virtualize beyond the limits of your physical world; this means additional hardware purchases are still a frequent reality. So where hardware virtualization is possible, it clearly reduces the hardware acquisition component of TCO, but that is only a small component of TCO. In the next post, I will cover how the service virtualization concept can greatly expand the benefits of virtualization.

Guide to Service Virtualization in Enterprise Application Development – Part One of Six

 This post begins a six-part commentary based on our white paper, Service Virtualization in Enterprise Application Development. It covers how service virtualization complements hardware virtualization with the ability to reduce cost and increase business agility across the entire software lifecycle. Each post will informally discuss some key points I'd like to make in conjunction with the paper.

Leading technology and business analysts cite the adoption of Virtualization as one of the most significant technology priorities of this decade. Virtualization at the hardware and data center level generates an almost immediate payback in with many millions saved IT operations costs. However, as we discuss in this paper, solely focusing on hardware Virtualization, we are leaving savings in both time and money on the table. In this post we will define virtualization in a general sense (traits both hardware virtualization and Service Virtualization share) and cover three main benefits.

Virtualization is the practice of simulating the behavior of a physical asset, such as a server or application, in a software emulator, and hosting that emulator in a virtual environment. The virtual environment behaves enough like the physical environment that communication with the emulated asset is just like the real thing. There are a number of value propositions associated with this practice.

• First, virtualization allows us to better manage physical assets. For example, many enterprises have troublesome configuration and change management issues. The additional abstraction of a virtual environment makes best practices around change and configuration management easier.
• Second, we can better leverage the capacity of physical assets with virtualization. Instead of every team acquiring its own hardware platforms for development, QA, and integration testing, the same servers can be leveraged between disciplines and even across teams. The goal here is to stem the tide of server proliferation.
• Third, virtualization helps organizations to be more agile. It is easier to reconfigure people than physical hardware resources. Virtualization increase the flexibility of the physical assets as we can better access the applications and services that we need immediately, and without time delays waiting on IT to switch servers or perform other reconfigurations.

In the next post we will look at how hardware virtualization sets the stage for added benefits from service virtualization. The complete white paper can be down loaded in our Resources section: Service Virtualization in Enterprise Application Development.

Podcast: Talking SOA & Virtualization futures with Peter Schooff at Gartner AADI

Last week I had the chance to catch up with eBizQ's Managing Editor Peter Schooff at the Gartner AADI conference in Las Vegas. Amidst the hubbub on the floor he taped this brief interview - take a listen:

http://www.ebizq.net/blogs/2008/12/beyond_testing_to_validation_l.php

The talk ranges from our SOA Test, Validate, Virtualize, to newer expansion of our capabilities into LISA Pathfinder and Data Management features over the coming releases.

Overall observations from the show? I'm glad I attended - the quality of the discussions was stronger than ever. And - even though the economy is tough and attendance at physical tradeshows is down, this particular conference was full of execs and technical leads who have critical business needs - as in, how do I eliminate costs and constraints from IT - that they need to solve NOW. Thanks to all the customers and analysts we had the chance to talk to there and all the best facing next year's challenges.

SOA Governance Panel Recap: Federated SOA for the Day

iTKO's John Michelsen recently served on ebizQ's SOA Governance panel for a spirited online discussion. Joe McKendrick moderated the panel which also included: Anne Thomas Manes, vice president and research director with Burton Group, and former Chief Technology Officer at Systinet; Ron Schmelzer, managing partner with ZapThink; Frank Martinez, senior vice president, product strategy for SOA Software; David Bressler, SOA Evangelist for the Actional products at Progress Software; and Ed Horst, vice president of marketing and product strategy for AmberPoint. Joe provided both a summary, Panel: SOA Governance Answers 'What's in it for Me?' Question, and the full transcript: see Transcript: SOA Governance Panel.

Joe charged the panelists to comment on how far along we really are with SOA, and what is needed to take things to the next level. He also wanted them to be practical, and explore the tools and techniques that are essential to getting started with SOA governance. In addition the discussion focused on the implications of SOA governance for the "Web 2.0-ish" activities (like Cloud and WOA) that are often well under the radar of corporate IT management. Lastly, he wanted to cover one of our favorite topics, virtualization and SOA.

As Joe said in the summary, setting up proper governance seems like the logical approach to introduce SOA to the business. However, in the real world, SOA proponents run up against a series of obstacles. Many stakeholders have to be signed on to the SOA effort. These include developers who are expected to reuse someone else's code, departments that are expected to share assets and timelines, functional groups that are expected to provide more funding than usual to the IT underlying their processes with the hope for future cost savings and greater agility.

In response to these challenges John suggested that a Federated approach may be essential to SOA governance. In effect, people may be more willing to accept governance at  more decentralized levels, rather than more centralized approaches:

"We found that it is very analogous to the governance analogy in the physical world. That federating or layering of the governance policy is how it happens. If you think about it, my homeowners association, it wants to know where I'm going to put my flag. But at the Federal level.. that would be an absurd notion for them to decide such a thing. So we are more tolerant of greater control closest to us, than we are far away. So if there’s this very distant group of people who decide on how we are supposed to build and consume services, then we will tend to react negatively toward that. But if there is even.. a fairly onerous set of policies, but it’s shared, and its owned by me and my close constituents, I tend to be more willing to do it."

Later John added that since SOA has been around for a while, we know in advance a number of things that require planning, including aspects of the governance requirements. The solutions require more that installing infrastructure, they require an understanding of the desired business behaviors and how this infrastructure will support these behaviors.  He also said that there are two types of governance: what operates during design and what operates during run time as the transition to the new SOA services takes place and new complexities come up. 

While the panel was not able to cover virtualization like we hoped in the hour, they did manage to cover  other topics. The panel’s responses provide a rich resource on SOA Governance and make a good read (or listen). Here are the participants. They are left to right: Anne Thomas Manes,  Ronald Schmelzer, Frank Martinez, David Bressler, John Michelsen, Ed Horst, and Joe McKendrick.

Thanks for the questions and comments, and those of you who stopped by our "virtual booth" for more questions. We're looking forward to our next one at the "SOA in Action" virtual conference Nov 19th 2008, which has a who's who of SOA experts throughout the day. John is participating in the "Avoiding SOA Disillusionment" panel at 2:00 PM Eastern with Joe and a new cast.

At VMworld - Provisioning Plays in the Virtual Box

I've been here at VMworld and I just walked every booth on the floor. A few notes: Half of the exhibitors are all about the monitoring and management of VM images. Lots of desktop virtualization companies offering a way to look inside the performance or operation of the VM "boxes" running in your environment. It is literally like everyone realized that a management/metrics dashboard for VMs was missing at the same time.

Several companies offering I/O virtualization -- which is a way to provide one big pipe and manage the provisioning of the users of that pipe. So for instance, we have a 100-meg connection to the Internet, and some team wants to consume some of that, so we need to provide a "virtual T-1" on top of the real 100MB ethernet... saving the dedicated capacity of that bandwidth "box."

Application virtualization (aka "Endpoint Virtualization" by some) is nice in that you aren't just getting a whole box, instead you get a set of apps that are provisioned just for you.  So I log in and get a programmer's IDE but our sales guy logs in and doesn't -- in fact he's not allowed near it ;)  Cool way to provision team members with their individualized boxes.

Virtual Test Lab vendors were there too like VMlogix and Surgient.  I don't know how many of these attendees are concerned with virtualization in development lifecylces but this is clearly an important space for virtualization in the larger context.

What's new? Skytap and other Cloud platforms were there, mostly grouped in the back by the fire escape in case there was a virtual battery fire. What is interesting is that VMWare has competing product with just about every software vendor in the building, save cloud provisioning, and I'm sure that's coming out soon enough.

I turned every corner looking for the banner that said "What about all those systems you can't image in a VM instance?"  Of course that's our offering with LISA Virtualize. So my reaction is that the market is still digesting the fundementals of virtualization.  It's a very operations focused show.  That's not "wrong" -- it's just leaving a lot of what virtualization can do on the table. I'm looking forward to virtualization concepts pervading the whole enterprise.

Outlook Interview Part Four: Virtualization and Testing

Here is part 4 of my recent interview with host Mike Lippis of the Outlook Series. We have broken the 45 minute podcast interview into five parts for easier reading. This section covers virtualization for SOA and how it affects the development and testing teams' productivity.

Mike:  “With this virtualized service edition of LISA.  What are you doing in the area of parallel development and test cycles?”

John:  “What we do is enable that parallel development, because we’re trying to decouple those service providers and consumers from each other during their lifecycle. 

“So a very reasonable approach towards meeting this kind of objective is that I might go through a requirement phase and a design phase and as I start development, I can discover my dependent systems, virtualize those dependent systems and then execute my development plan against my virtual services.  When I do this, I am decoupled from all of those constraints on my peers or on all those other services.

“The reason that I do this is because:  we’ve all heard our development leads say, ‘by the way I haven’t been able to do anything today because the “so & so system” is down.’  Or, ‘remember…they gave us a new build yesterday? Well the new build doesn’t work … they broke one of the major operations. So my team hasn’t had any productive time during the last two days.’ 

“We hear this all the time … this live connectivity to everybody (remember that white board I just mentioned a minute ago?)  Live connectivity to all of these boxes creates a large amount of friction or construction barriers, if you will, in the road. 

“What we can do, by isolating ourselves from that through virtualization, is we can parallel that development activity and, of course as a part of our final integration testing we go from virtual back to live services.  Once we are all live, we can obviously make sure that everything inter-operates the way we expect.  The value here is that instead of having to wait for my dependencies to complete, I can run in parallel with my dependency and get it done faster. 

“A quick example of this is:  If I’m asking you to implement a new feature in your service, I have two choices:  I either ask you to make that change and wait for you to make that change, test that change, produce that change into a build for me and make it available, or I can use a virtual service.

“I can make the change in the virtual model very quickly (we are talking minutes to do this with our product) … and I can be developing in parallel against the virtual version of your service just an hour or two later.  Meanwhile, you’ll take weeks to produce a new version but I’m developing against the new version in parallel in a virtual world.  Once your service is complete, I can point my application away from the virtual edition, and instead to the live edition, and we can make sure that it actually works as we expect.”

Mike:  “When it comes to testing in this area, we certainly want to simulate as many data set combinations as possible to see how effectively that this solution is working; how robust would release be in that area in terms of being able to simulate data set combinations?”

John:  “We’ve spent a lot of time on this.  It turns out … as we embarked on this virtualization strategy, we knew that virtualizing data layers would be a big thing, but I can’t tell you how many times I’ve heard our customers say “this is the big thing.”  It’s because of all this data synchronization, and all of this volatility of data – every team wants to reset the database every time they run their test and every time that they do a development cycle, and that means that no two teams can be sharing the database at the same time, and it’s always a mess!  We’ve spent a lot more time here than we’ve even thought and we’ve solved a lot of problems here.

“A classic example of this is:  When you are working on the purchase ordering system, and the supplier system is your partner, you don’t actually produce the supplier’s service, but you talk to a supplier … and yet you’re supposed to build an application that tightly integrates with your supplier … how do you do this?  Well again, you virtualize either at the behavioral layer or the data layer.  And, why do you virtualize at the data layer?

“Think about it … the supplier could respond to a PO request by supplying all of the requested goods at the requested date with no issue; but the supplier could just as easily split the order, could partially cancel, could respond to you that these items were no longer carried, could warn you with a credit check, could warn you … The number of possible data scenarios in the response to a requested PO -- it reaches the point where we wonder how we can possibly test all these out. 

“Since we can’t drive data scenarios in live systems, we can’t drive data scenarios with our partners -- at least we can’t effectively -- we need to virtualize that database so that we can drive all those.  I can make certain that every kind of possible response to a PO request is available to me all of the time.  That’s what data virtualization does for us.  It makes me able to make certain that every time I need the stars to align a certain way for me to make a certain condition occur, I can do that.  I’m certainly not strong enough to literally make the stars align but, in a virtual world I can, so in that way I can always make sure that everything works the way I expected.”

Mike:  “There are a number of load and performance testing tools such as LoadRunner or SilkPerformer, and a lot of companies have made investments in those technologies, so how can they leverage those investments that they’ve made and expand on those with LISA Virtual Service Edition?”

John:  “That’s absolutely true Mike, there’s plenty of successful LoadRunner shops and SilkPerformer shops and others, and LISA does load testing, but we’re certainly not interested in trying to fix what’s not broken.  We’re certainly quite comfortable with working with companies who are doing load testing with LoadRunner.  A number of our virtual services environment customers are doing exactly that.

“In fact, if you picture in your mind:  the left-hand side of the graphic is Load Runner generating a load on a system in the middle of this graphic and on the right-hand side of this graphic is LISA Virtual Services environment.  What we do is enable more and better load testing even with the tools that we did not provide.  What we’re doing is we’re freeing the system that you’re testing from its constraints.  We’re not eliminating that system nor are we trying to affect the load test product itself.  We’re actually trying to virtualize away the constraints on the right hand side of the graphic. 

“So, it’s LoadRunner, versus the System Under Test, which can be LISA … and that triad, if you will, makes for a very powerful load testing combination.  What we have found is that you have to have production hardware or at least a reasonable production performance lab for your own application. 

“Our customers understand this, what they have trouble with is:  ‘Wait a minute, my application no longer lives on its own island, it now goes and invokes its own transactions on a main frame or it now integrates between a TIBCO-based system or this web message-based system and it goes and talks to this ERP system.’ 

“In order for me to performance test my application, my performance lab just went from a half million-dollar investment to a five million-dollar investment … and that’s what they can’t do.  So when you go Load Runner/Your Application/LISA, you eliminate the five million-dollar investment. You literally eliminate it.  What you go from instead is the half million-dollar investment in your hardware platform -- what you have to run your application and your service on, and we virtualize away all the heavy iron that you have to connect to.  We put that on a commodity box, what would be a rounding area on a half-million dollar investment -- we would run on a $20,000 server.”

[This concludes part four. In the next post we wrap up the interview and provide an overview of ITKO.]

Outlook Interview Part Three: Performance Management and Testing

Here is part three of the interview with host Mike Lippis of the Outlook Series. We have broken the 45 minute podcast interview into five parts for easier reading. This section covers performance management and testing.

Mike:  “When it comes to really achieving business value from IT investments, lots of folks will really look at performance.  Can you give us some background on some current performance management strategies that are out there?”

John:  “I can compare that to what our traditional approach to performance management has been and again, if in the old world, entire applications were produced and then they were performance-tested in a lab and released for production.  This worked okay when the thing we built was a 100% self-contained thing. 

“But now back to an analogy of a service-based architecture, where I am producing applications that consume services from you, Mike.  What do you do to performance test or to manage the performance of your service?  You are no longer a complete application.  I can’t ask you to produce your service, and send it individually into the performance lab if the performance lab hasn’t retooled?  I’ve got to think about performance testing at the services layer.  I’ve got to think about the performance testing even at the orchestration layer.  By that I mean there may be two or three services that collaborate to make one business process or even one sub-process of the business function. 

“Once we start to think about performance management, now that I’ve broken my big box application into a number of components; I’ve got to do the same thing with performance.  I’ve got to break my run-time SLA into the component-level SLA  (Service Level Agreement) that’s basically my performance and resource expectations that I’ve put on my applications.  So, Mike, I might need to do something that we call decompose the SLA where my application must run at 2 seconds or less response time for the user.   

“If 2 seconds is what I have -- I need to get your performance under 2 seconds so that I can meet my SLA.  Your response time is a component of my response time, because I am invoking you -- I am dependent on your service.  What I need to do is negotiate (for lack of a better phrase) your SLA with you--we call that decomposing the SLA.  You need .5 seconds, then my application can consume 1.5 seconds, and therefore, I can meet my overall SLA.  This is in many ways a new way of thinking about performance than previously.   We used to just think about 2 seconds -- we dropped the application in a lab to see if we had 2 seconds.  Now Mike’s team has to go to the lab and has to meet .5 seconds, and my team has to go to the lab to meet not 2 seconds but 1.5 seconds. I’ve got to make sure that my 1.5 seconds will combine with your .5 seconds.
Make sense?

Mike:  “Once you have an application completed, a lot of times they are difficult to tune for performance.  What are you specifically doing to address that?”

John:  “This notion of taking our SLA apart into components actually helps us do this.  It does for a couple of reasons the biggest is:  if we can performance test within the life cycle, if we can do our testing as a part of our own development than we can find and resolve our performance issues much more quickly.  In my experience, and I bet many people in the performance field will nod in agreement, so many times if we build an app that does not scale and then try to tune it into scalability, the best we’ll do is 10 or 20% improvement.  You can’t add hardware and make a product that is un-scalable all of a sudden scalable--it just doesn’t work.  If you had known earlier where those scalability issues are--than you can build in the scalability along the way a whole lot easier.

This is essentially the same reason why we iterate from a requirements definition standpoint, because the more we iterate thru the scope of our work the better we are at delivering on it and the faster we are   The same is true with performance, we have to iterate and we have to do performance testing at the component level in order to get that performance up and the scalability up.”

Mike:  “Are you doing anything to address the challenge of discontinuous development cycles?” 

John:  “Yes.  Because of the fact that you may be building your component at a different lifecycle pace than my application even though I am a consumer of your component, (usually we call that service) our challenge is that I got to have access to your service maybe at a time you don’t even have it ready for me.  You might have down stream dependencies of your own.  As soon as I think of you as “Order Management” -- you might turn around and say: Yes, I do order management but I sit on top of the customer database that I don’t own, and I sit on top of the ERP system that I don’t own either.  So, you have your own set of dependencies.  So if we actually fit it on a white board, most large-scale enterprises would literally fill a white board with very small little boxes all interdependent on each other and they are all iterating on their own life cycle.  It drives me nuts just thinking about how anything actually works!

“So in order for us to support this kind of distributed lifecycle, we’re doing a lot more virtualizing of the components underneath each other. 

“What we mean by this is:  since I am invoking your service, I am dependent on your service, but what if your service isn’t available to me yet, what if I need you to change your service and your changes aren’t ready yet?  What if I need to do performance testing of my application on an interim basis but I don’t have scalable production quality hardware to run your service on?  Or, maybe worse, maybe your service talks to the mainframe, but I don’t have availability of mainframe resources to do this?  All these are what we call constraints.  These are real world constraints which we are dependent upon. 

“What we do is:  we virtualize the behavior of these things.  What I will do is construct a model (our LISA Virtualize product is really good at doing this) -- it constructs a model of the behavior of your service, and once that model exists I can run that model in a virtual environment, it doesn’t have to have the real world constraints; it’s a virtual thing.  So, if I need it early, I’ve got it. If I need it to scale to 500 transactions a second, I can do that. Even though I don’t have production type hardware for your real service, I can virtualize it and get the kind of performance that I’m looking for.” 

Mike:  “It sounds like you would be able to provision the right hardware and platform for a given solution then.”

John:  “Right, because what we do is that we dramatically reduce what that requires.  A classic example for one of our customers is:  I’ve got an application that is a portal-type application that invokes a set of services.  Some of those services talk to SAP.  SAP is a great ERP system and many large organizations use it; but of course we don’t want a lot of performance and load testing type transactions against that system.  We don’t always have availability when we need it.  We don’t always have the data in the database when we want to -- SAP testing is a very complex field -- so there are all kinds of real world constraints.  What we do is we virtualize the behavior of SAP and in doing so, your portal has access to what it needs 24/7 and I don’t have to provision the entire SAP environment to do it.  All I have to do is provision my own application, we can’t virtualize away you --but we can virtualize away your dependency. and once we do that, we decouple you away from a lot of the challenges that those constraints have.”

Mike:  “When it comes to performance labs, it seems like a lot of them really rate data management as a very big problem.  What can you tell us about dealing with that challenge in leveraging LISA?”

John:  “One of the great challenges with data in performance labs … is really two challenges. One is that you can never talk to just one database in a performance test. You are usually dealing with multiple data sources.  For example (as I mentioned a minute ago), order management is dealing with a customer database in one system and with the orders database, let’s say, underneath SAP -- so here’s two completely independent systems that are now interdependent on each other with regard to data.  Now here I am in a performance lab and I’m trying to support hundreds of scenarios of real world use of my application.  In order to do that, I need the data between those two databases populated in a certain way and synchronized between each other and whatever changes are made in one database, I need those changes to be reflected appropriately in the other database.  Do you know how often this happens? Much, much less frequently than Christmas! 

“What we have is a dynamic that we see all the time, you’ll go into the performance lab wanting to do some 100 different scenarios of use, these are all the use cases you want to be sure are performing and scalable in your application; but by the time you figure out just how to get all the data to synchronize between these two systems, the best you’ll come out with is about 20.  Now the problem is that you’ll performance test just 20 scenarios, but you’ll go to production with all 100.  You’ll find out the hard way whether the other 80 are a problem or not, because your real world users will be doing those other 80 (the one’s you couldn’t performance test) and the problem is:  if you have scalability or performance or resource issues in those other 80 … then you have a problem.”

Mike:  “When it comes to best practices in the area of performance and load testing, what can you tell us about decomposing performance expectations?”

John:  “I gave a quick example of this earlier, I’ll elaborate on this a little bit. 

“If the production SLA for a particular application; let’s say mine is 2 seconds…that’s the example that I gave previously … where my response time to my user is 2 seconds … but one of the things that my application does is to consume services from your team, Mike, I need to negotiate your response time as a part of my response time.  So what I do is decompose that SLA.  What I’ll do is say, ‘okay, I’ve got to make sure that I can get Mike’s service calls in a short enough amount of time so that my application overall’ -- once you add up all of the time consumed – it doesn’t trip over our expected response time. 

“So we help by giving the customer the ability to do two things.  The first is:  we’ll help them do performance testing at the component level.  Mike, you can performance test your service.  You can say, ‘hey John, I can hit my half-second response time metric independent of you.  I owe you the right functionality at the right performance.  I can functionally test this system to make sure it works and I can performance test my service (independent to the rest of the world) at .5 seconds so I have done my job.’

“Now, I come into the picture and I can do performance testing on my application and make sure I hit my SLA as well.  In order for me to hit my SLA, I have to take you out of the mix. That’s why we talk a lot about virtualization in the performance lab. 

“So second, I can simulate your service’s behavior and I can even simulate your behavior at .5 seconds.  I can say, ‘alright Mike’s virtual service; I want you to behave like Mike’s virtual service, and I want you to take .5 seconds whenever you respond to me.’  By the way, I can even say ‘what if.’  What if your response time takes .6 seconds, what does that do to my overall response time? What if you’re actually running a little faster at .4 seconds …what does that do to my response time? 

“Sometimes the fastest way for me to get better scalability is to negotiate you a little faster so that my application hits its SLA:  stuff like that.  So that’s why performance testing as a component and virtualizing married together really give you a solid foundation for performance management in SOA.”

Mike:  “We had mentioned provisioning before, how does that come into play in terms of optimizing provisioning relative to managing performance; should one be done before the other and how is that relevant?”

John:  “The relevance is that we need to be able to capture virtual services as a part of the provisioning activity.  Where in the past, I needed the entire SAP system to be available for provisioning, now I just need the virtual services that encapsulate the behavior of SAP; I need that to be the provision item instead of the whole SAP system. 

By the way, when you think about these large-scale applications, often there are not only many servers with a very specific and complex kind of configuration, but there are huge databases underneath these big systems.  So very frequently we have customers tell us that they can’t do development work against this massive system because it’s got a terabyte-sized database underneath it.  In order for me to get access to it, I have to wait till midnight to 2 a.m. because that’s the only time they will give me time on the system. When I try to do performance testing, they refuse to let me because in order to avoid impacting production, they limit the amount of non-production activity on that particular system.  All of these kinds of constraints are those very same kinds of things. 

“So, back to provisioning, if I need access to this particular database or this particular large application that spans many servers, I encapsulate all that behavior into one virtual service and I can provision that one unit to represent that entire set of systems.”

This concludes part three. In the next post we cover virtualization and testing.

Outlook Interview Part Two: SOA Testing Best Practices

Here is part two of my recent interview with host Mike Lippis of the Outlook Series. We have broken the 45 minute podcast interview into five parts for easier reading. This section covers SOA testing best practices.

Mike:  “Service Oriented Architectures really have been around for a long period of time, and it’s really not a certain thing but more of a style of doing something.  If it’s a style, there’s going to be different kinds of approaches -- lots of interdependencies and something that’s going to continuously change and evolve.  What are you doing in the area of SOA testing and addressing those kinds of structure flow issues?”

John:  “That’s a great point because you’re right; the concept of component-based applications has been around for a long time.  I’m going to show my age here, by the time we come to the end of this conversation, you’ll know that I’ve been around a little while… 

“Our approach is basically the same as it has been for many years:  let’s take business logic and let’s encapsulate it into objects so that they can be leveraged across applications.  Let’s start to layer systems by their responsibility or domain so that we can build applications that are specific in terms of their interface.  For example, I might have a voice response unit for telephone callers and I might have a call center application for users on the phone but I don’t have to rewrite all of that logic every time, and I can make changes to business logic more quickly that way.  We’ve been talking about that concept since the late 70’s.  What makes SOA different today is that we are accomplishing it more than we ever had in the past due to the commoditization of middleware.  The fact that there is highly available, very reliable and also very understandable and cheap middleware means that it is possible to build these applications today.  So we are actually accomplishing it more than we used to in the past.”

Mike:  “I’ve seen in some of your collateral that you talk about the three C’s for some time now.  Can you tell us what those three C’s are and educate us as to what you have been doing and kind of describing the problem in that framework?”

John:  “The 3 C’s are our framework for best practices for SOA testing.  What we say is that if you have those 3 C’s right, than you are in good shape for having sound SOA test strategy. And, you can imagine our product LISA is a great way to accomplish these three C’s.  However you do it, you need them because essentially this is the standard now, so how do you reach it? 

“The first of these three C’s is “COMPLETE” and it essentially acknowledges the fact that this is a heterogeneous layering of technology. We must support a concept that we call Invoke & Verify.  If I invoke at one layer of technology I have to actually verify the outcome I am expecting by going to a different technology layer.  For example, if I go to an ATM and I deposit the money in the ATM and if I trust the receipt that it prints, that’s not really testing.  The way I test the ATM is by calling the bank teller or by going to my web site and looking on the web -- I go around the actual device that I am testing so that I can prove the outcome that I’ve expected. 

“The second of these three C’s is COLLABORATIVE.  Collaborative basically requires us to do more parallel activities and to leverage assets more rapidly than we had in the past.  Agile and SOA are usually tightly aligned.  In fact, most CIO’s tell me ‘I’m going SOA so that I can become agile.’  They are very linked at the highest level in most of our accounts.  Because of that, we need to do more in parallel and more shared. 

“The third of these three C’s is CONTINUOUS.  This essentially acknowledges the fact that we can’t test as an event along a life cycle anymore, and think that this is enough.  The fact that I’m dependent on let’s say your services Mike, means that I may test my applications today -- deploy this Friday and the following Monday you update a service underneath my application and threaten or risk – there’s our word - risk failure of my application in doing so.   So our strategy calls for a continuous validation of functionality, performance and certain policies on a continuous basis, - that’s the
third ‘C’.”

Mike:  “You have a product that’s called LISA.  How does LISA specifically achieve these three C’s that you just described?”

John:  “Breaking it down a bit, we support all of those different technologies from a COMPLETE point of view.  Whether it’s web technology, Thick UIs, messaging layers, web services, older protocols like CICS and CORBA … all of those kinds of things; we support all of those different technologies from the same test case.  It’s very important that you be able to do this in one test with one product.  If you buy three or four different products to accomplish one test scenario, that is way too much effort and it is very difficult to try to integrate a bunch of testing tools to make one test.  It’s really not feasible to do -- you need to have all of these technologies covered in one workflow.  That is why we differentiate in many ways on the ‘COMPLETE’ C. 

“For COLLABORATIVE, we provide the ability to do Development type testing, (whether that’s Unit testing or Service level testing), Functional and System type testing, Performance Testing, even Functional Monitoring all as one unified test from one product.  We’ve got to leverage each other’s assets more.  Developers need to start the testing process, QA needs to consume and extend, if you will, with development based testing, etc. so that’s how we support the COLLABORATIVE.   

“For CONTINUOUS, we actually provide both continuous integration support so we integrate continuous integration-type tools … build tools like ANT and CruiseControl and all those types of things.  We also provide our own infrastructure for integration labs, for production, for pre-prod type systems enabling us to provide our own infrastructure for continuous validation.  Therefore, we specifically support those three C’s in our product development and design, so we can accomplish these best practices for our customers.”

Mike:  “It really sounds like SOA testing is a key part of overall IT governance then.”

John:  “You know testing clearly is -- it’s gotten much more relevant in the last few years.  It used to be just a step along a time line: ‘we make sure we test it before we let it go into the wild’ -- and that was just fine.  Today, because we have a greater degree of reuse expected, and because we have a more distributed development force -- where they are not even always us -- sometimes it’s ‘us & them,’ unfortunately, where I’m supposed to trust people I don’t even meet or know.  Because of that, the need to test has become greater and the possibility of failure becomes greater along with it.  So testing has become a much more critical focus of both development and even of governance.  In many ways test is the means to instill trust which is, of course, the goal for governance.”

[This concludes part two. In our next post we cover performance management and testing.]

Outlook Interview Part One: Current Business Trends and SOA Testing

I was recently interviewed on the program:  Outlook Series with host Mike Lippis, and we covered a variety of SOA-related topics, from Testing -- all the way to Virtualization.

You can listen to the 45 minute podcast interview here, but our team has also broken the interview into five parts for easier reading. Here is part one -- which focuses on SOA Governance and how companies are attempting to use this discipline to meet  business goals.

Mike:  “Can you share with the audience what are some business trends that might be driving any kind of shift in IT environments currently?”

John: “The business is why we are here.  So what we need to do is to align our initiatives, as an IT organization, toward what the business is trying to accomplish.

“Among these (initiatives) are to increase the agility that we have to their customers in terms of responding to regulatory pressure…new market competitive pressure, etc.; to reduce cost…to go global…to either be acquiring or to become a part of larger organizations (M & A is becoming quite common, especially right now), and then, of course, compliance is over-riding all of this in that -- even though we’re increasing the speed of the train, we need to be more careful about how we execute along the path.”

Mike:  “What kind of IT initiatives would be driving that besides things like SOA and virtualization for example?”

John:  “Those are certainly two of them, as the business is trying to reduce cost, we need to increase our leverage and reuse, and so Service-Oriented is certainly one way to do that.  To increase our speed of development we need to take a more agile process, we need to leverage and extend technologies more often than bringing in new siloed systems.  Reducing costs often is reuse, but it is also outsourcing and off- shoring and virtualizing things.  So there is quite a bit going on in IT in order to accomplish these business objectives.”

Mike:  “Sounds like there’s a new IT environment driven a lot by SOA and Virtualization.  Could you describe some of the downsides associated with these new IT environments?”

John: “For all of the goodness that we are trying to bring about by increasing inter-connectedness to leverage and extend -- reusing existing assets, and the improvements we’re trying to provide by increasing our pace of change, (we’re releasing software updates to our business users more frequently than we were in the past) -- those changes are more interconnected with lots of different systems than they were in the past. While those are good things; the unfortunate outcome is that we’re increasing our risk of failure every time we increase the number of times we do something and every time we increase the complexity in which we do something, we necessarily have an increase in the possibility of failing, so we have to address that.”

Mike:  “So, it sounds like you’re really looking at minimizing business risk in terms of what your overall mission is at iTKO.  Could you kind of drill down into that a little bit for us to kind of see how you are addressing some of those issues?”

John:  “You bet - and that’s a good point Mike because we frequently get asked: ‘If you’re in the virtualization space why do you also offer testing?’  Well, because the real business we’re in is helping to resolve the risk associated with service-based architectures and agile processes, and more generally increasing complexity and increasing paper chains.  So what we try to do is:  if we can help enable these positive effects without the risk; we’re doing so to shorten the time to market, to reduce the failure rate in production, to increase our recovery time when there is a failure, and in general then to reduce the total cost of maintaining our own ESB systems that we produce.”

Mike:  “When it comes to SOA testing which is a big part of what you do, what are some of the challenges surrounding SOA testing?”

John:  “There are a number; the one that’s most common is that SOA increases the likelihood that we just can’t manually test -- we have an inadequate level of testing in many organizations from an automated standpoint and this becomes the governor on how frequently we can make changes to our system.  If I have to manually revalidate an application any time anything changes, then I can’t change it fast enough.”

Mike:  “I would think that today, based on what we’ve discussed so far, in terms of all the complexity, you really have a lot of heterogeneous environments and or most IT environments are very heterogeneous in terms of the technology that‘s now being used.  So how does this come into play with the SOA and what you are doing?”

John:  “Well it definitely scratches that problem quite a bit.  The reason it does is because:  Instead of thinking: my application is this completely self-contained box that I deliver to my users and they use it directly; rather, many teams are now building components of an integrated system and those components are, (as you say yourself) in heterogeneous technology, where there may be existing legacy CORBA applications and main frame applications and even mid-80’s mainframe messaging architectures, and modern messaging architectures, and all of these things being brought together for one application.

“So, we have a real challenge here when we try to test a system like this, we can’t just test each individual box independent of each other (although we should do some of this certainly) we must be able to test across the work flow as the business executes, so we must be able to test across these heterogeneous boundaries.”

Mike:  “You had mentioned earlier-on that IT initiatives, such as outsourcing and off- shoring for example, are very common in today’s global economy, how does this come into play with collaboration and to what extent does this frustrate collaboration; what are you doing in that area to make that a more seamless exercise?”

John:  “So the short version of a very long best practices story is that it necessitates collaboration, and it really does because:  what we can’t do is to have completely disjointed applications being developed -- we need collaboration.  Collaboration comes in a variety of ways.  One is we need visibility, the ability to touch all of these different technologies and view through all of these business processes all the way down into the implementation technology.  That’s just one simple way.

“Another way is we need governance in place that better creates a structure in which we all can predict how we are behaving.  The more reasonable governance is in place, the better we will all function and the better the trust there will be in this very disconnected world that we’re building and maintaining with that.  So there are a variety of things that collaboration encompasses but that’s certainly two of them.”

[After setting a little context, the next post picks up with a discussion of SOA testing best practices, our three C's. Stay tuned.]

ESBs Cohabitating in SOA: Controversial?

I had a talk with Rich Seeley from SearchSOA a couple weeks ago, and his article: "SOA Complicated by ESB Proliferation" reflected how our discussion turned to what we're finding is an inevitable reality of SOA in large enterprises: the need for a team to manage and validate the Intermediation of different ESB and integration platforms.

Then this from our peer David Linthicum: "Are ESBs Hurting SOA?". Well usually we have seen eye-to-eye on many issues, especially since we are in the "platform neutral" space of needing to govern & validate the leading platforms on the market. In fact, we just sponsored a paper Dave authored "Testing & Validating Heterogeneous SOA" coming out soon that talks about how to design and validate these kinds of heterogeneous platforms. Dave is likewise not beholden to one ideal platform or solution.

Was I wrong this time on so many levels?
And who knew there was a controversy around ESBs in SOA?

That article spurred several comments for sure - and I had to put my own in there. We have also heard from a few more experts weighing in on the topic - Jeff Schneider didn't really see why it was a big deal in "Linthicum on ESBs," after all that kind of reality is likely what he is solving every day in his practice, while Loraine Lawson had a very good post "Multiple ESBs Causing Problem, but Nobody's Listening," supporting Dave's point that we need to do much better architecturally, and not just accept it as a reality.

Now to caveat, I was actually talking about it as a challenge -- I was never recommending multiple ESBs as an ideal approach - but it is certainly not out of reach to manage well with good intermediation practices. Companies putting all of their eggs in the basket of mediating strictly at the web services layer also run into a proliferation of different standards and metadata, or the "JBOWS" conundrum -- I addressed this recently in a brief -- and it is hard to dictate that compliance unless you have a very tight grip on standards, and for most large companies, the standards around services aren't consistent. So if you try to enforce too strict a compliance, you end up with poor reuse.

With multiple ESB platforms, you are still providing a very good way to bring underlying business applications and transaction systems to bear with an integration and messaging framework, sometimes with business process management as well. Yes they are different systems, but they can be pulled together effectively as long as the validation is there, and as long as the multiple teams have a means to virtualize their dependencies and continue developing and testing new functionality.

Obviously you would like to start with a clean slate and architect the system from the ground up with well-defined semantics, proper levels of service granularity, get partners delivering on the same standards, and realize the reuse and agility benefits you expect from having a very modular system. But, given the reality of acquisitions, partnerships, and the need to support ongoing businesses and their heterogeneous technology at consistent service levels, most larger companies need to find a way to get these systems to play together nicely.

We have to reconcile ourselves to this fact: the likelihood that there will only be one platform participating in business process execution will decrease, when there is a broader distribution of the business process. Departments may mandate homogeneity, but inter-enterprise transactions couldn't possibly do so. SOA is about abstractions that make disparate things work together.  Let's leverage this pattern to bring these systems together.

Now Dave just came back with a rebuttal in Real World SOA: "Madness I say!" - and yes, I do understand where he's coming from. An ESB does not a SOA make, and, yes, more centralized control would improve the situation. Still, I'm right on so many levels as well though... : ) We often take the tack of "SOA Federation," which is akin to the idea of Federal vs. State authority: a central (Federal) authority that dictates some ground rules and standards for interacting, but leaves much of the specific technology decisions such as which ESB to use, to the parties (or States) that provide and consume the shared services.

When you take SOA as a multi-enterprise workflow of a consortium of partners working together, centralized control is practically unattainable. You can't just dictate that partners follow your policies and your architectural decisions.

I’m a big fan of both leverage-and-extend, and iteration as a means to an end. I'd submit that the greatest IT value of a service-based architecture is that it enables these things. With them, I can be more responsive to business needs faster. I'm also too much of a realist to take a 'puritanical' view of how to build out an SOA.  We have to try and refine over time.  So I'd rather "grade" SOA on its level of maturity, not call it something else.  For example, ungoverned web services used within a tightly coupled team is an immature SOA; broadly distributed services leveraged by a variety of consumers with increasing development responsiveness is a mature SOA... 

If I am a business, I want the benefit of being uninterested in the implementation technologies deployed under the service interfaces I consume, so long as the governance and testability are there. Why preclude any technology from making its contribution to SOA, especially one that is doing fairly well at the job like ESBs?

I love a good back-and-forth on these kind of issues. I've talked to a few other bloggers/columnists since then, and I'm sure we haven't seen the last of this debate. To me it says that the practices and methods for SOA are still evolving, and there are a lot of good people passionate about working on these issues. We may never arrive at an "optimal" SOA but I do believe that IT will get better at addressing business needs if we keep signing up for solving the hardest problems while ensuring continuity today.

More comments on the ESB and SOA hullaballoo...

• Joe McKendrick is a little surprised ESB is this big a story as well... who knew?
• "So how SOA are ESBs?" Michael Meehan in Search SOA puts it in perspective.
• “ESBs on trial?” - David's third post this week on the topic (He's taking some fire, but maybe liking the attention?)
• “Businesses aren't machines, and enterprise architecture can't make them so” - Neil Ward-Dutton's commentary puts the business first...
• Dave makes his... Last ESB/Architecture Post, For Now
• Tony Baer in OnStrategies apparently missed the whole debate while on vacation...

WS-FalseSecurity: Are you at risk?

In our previous post, we mentioned how the notion of standards in SOA can be just the opposite. This is largely because the standards are generally generated by whatever tool you are using to create services – it’s not something you construct by hand. “Compliance” is never a 100% proposition.

Well, I wanted to take a moment to talk about the idea of Security in an SOA world. We’ve seen some similarities in this space – particularly, that WS-Security is thought of as a means to ensure that SOA applications are actually secure in practice.   We've seen from our customers that QA and IT operations teams actually do have access to test mainframes in production - to run test suites and validate that unauthorized parties can't get in. That level of rigor around access got harder to maintain when we moved to a services-based model of software -- but the security technology of some leading vendors and platforms is doing a pretty good job of validating and keeping up with WS-Security, even if it comes in several proprietary flavors in execution.

However in reality, compliance to web services standards, like WS-Security protocols, will never even come close to providing the level of security we need from enterprise applications. Most of your business logic and behaviors -- beyond ensuring the “hookup” for the services themselves is using some form of this protocol -- are happening far below the service in the functioning apps and systems of record.<

These systems are owned and managed by different teams, inside and outside your domain of authority. So what is the answer? More detailed testing of the OASIS definitions of commonly encountered violations and loopholes at the WS-Security layer?  Automated unit testing of security protocols is important – we do it in every engagement. However, we need to remember that a set of 100, or 10,000 different protocol checks is still just that – it is only testing for the kinds of attacks we already expect.  We can set up wire fences and checkpoints, but what happens once you get past that point of entry into the application?

Take for example a Sales department that is leveraging an SOA application to collect buyer interest and respond to customer opportunities, but is not automating its own process as a secure service. Since the management insists on a spreadsheet-based process, the sales guys copy or export the customer data into a spreadsheet, send that spreadsheet all over the company, then enter orders back into the SOA application based on the results of the sales meeting and customer calls. What happens when that spreadsheet inadvertently gets attached and emailed to a supplier?

Or the IT guy who creates a handy service that scours the application for all available products and inventory, and then publishes that for a reseller to tie into their own order application. Soon word spreads, and 100 resellers are drawing data out of that service - creating a performance and availability nightmare that was perfectly authorized, but never intended.

The biggest loophole in your systems hasn’t changed. It’s still the guy in the cube next to you, or the partner on the other side of the transaction. It is the unexpected behaviors of that next service you hook up with your own. The agility of SOA – its greatest strength as an architectural model – is also its greatest weakness. It just means that there are many unintended ways the Security of your applications can be compromised, besides the misuse or improper use of the WS-Security protocols.

Real trust will not come about simply through compliance. Security in SOA will be a matter of coming to grips with the way an unknown quantity of users and other services could exploit your services in unintended ways, and how the services you depend upon can possibly compromise your carefully planned exterior when they are passing transactions through your application. That level of prevention simply can't be automated - it becomes a matter of finding the integration and interface points where you have the highest risk, and prioritizing the automation of testing there first, both at a “compliance” level and the interaction level.

Prioritizing and addressing risk is the only way to truly avoid the most risky behaviors. Of course, these concerns must be met in a timely fashion, and balanced with actually allowing customers to use the intended functionality. Good automation, and virtualization of services, reduces the time required to test while also eliminating unwanted behaviors, so end users can still get the access needed to work with your applications.

I welcome your comments and examples on this topic! We'll be posting more examples of behavioral security and how to limit the your business exposure to risk soon.

So you have a SOA Management Dashboard. How do you drive it?

Lately we've done a lot of research and publishing on how Dev & QA teams can ensure better quality throughout the software development and release lifecycle. But what about the IT Operations guys?

It seems we are encountering a disconnect between the Enterprise Architecture and Integration disciplines that are moving to SOA, and the people who need to monitor and maintain these systems in deployment. There are a lot of companies starting to focus on better SOA Governance, which includes the management of business processes and workflows, and the services and applications behind that. Great stuff happening on that side of the IT shop.

However, often the actual running applications are still in the purview of IT Operations teams. Don't get me wrong, it is a great thing that we have a team that is manning Mission Control -- hopefully providing an impartial report and monitoring function that is crucial, when you have live customers depending upon these apps in deployment. And there are mature tools out there that provide this kind of live "dashboard" of how the implemented apps are performing, like TIBCO Hawk, HP OpenView, IBM Tivoli, CA/Wily, etc.

So why would these IT Operations teams be interested in SOA testing and validation? Well, it's really about "causing the cause" of performance and latency issues in these systems. If you are trying to prove that live SOA infrastructures are ready to roll, it's not enough to sit and watch the dashboard for that "Check Engine" warning light when a condition is caused by too many customers using those apps.

The point I'm making is to use automated Test Execution as a way to drive expected and unexpected behaviors into your SOA Monitoring dashboards. This can be done both at integration time in staging, and against live applications, if you can provide a test window of time to make this process happen.

For instance, we recently worked with a large energy industry customer who wanted to prove that their live implementation was able to handle a realistic profile of varied transactions in their system. So instead of waiting for a rush, they manufactured one -- by executing automated test transactions into the system, and monitoring the performance results within their Operations dashboards. Then they could feed the same data out to their SOA Testing platforms to tell the tests if they performed according to service levels.

We recently put out a little news on this kind of integration - it's a pretty exciting way to apply Test & Validation to the Monitoring applications that have been around and evolving for some time: http://www.itko.com/site/company/news_65.jsp

To me, that is a better machine - and it takes away a lot of that disconnect between Development and Integration teams, and the Operations people who are ultimately answerable for customer service levels.

SOA Best Practices: Continuous Testing and Validation

Several weeks back I gave you a real life experience that typified why our test strategy we call the Three C’s has Complete as one of those C’s. This blog will give you a different real-life experience on why Continuous deserves “C” status.

I was meeting with a Director of development at one of the worlds largest financial institutions. Many of their trading applications have absurd levels of complexity and variability along with, of course, radical performance expectations. Really cool stuff.

A certain critical service was running on a major SOA platform. The vendor released an update to that platform, and the team responsible for this service ran their unit and service level tests -- doing more than most teams I’ve seen. Turns out, they all passed, and in fact the service performed its main function 12 milliseconds faster -- COOL!

Then again, maybe not.

They deployed the patch and watched their entire currency trading system grind to a near halt!

Wait, you sped up the service and slowed down an application? Yes. Turns out the performance of the service prevented timing issues in the orchestration layer from surfacing in use by an application.

Of course it wasn’t obvious to the team that this was in fact the issue -- they were blaming the vendor, then their new code changes looking for how they could have wrecked the performance. They went on for days losing millions until they figured out what was really happening.

The Continuous C solves for this type of problem. Take those same tests you would automate at the orchestration and solution levels and run them on a continuous basis at those points of integration, pre-production. You’ll get immediate notice of this type of issue along with much clearer identification of the root cause.

European SOA: Ahead of the Curve?

I'm in Germany right now, looking forward to a session at ZapThink's Practical SOA in Frankfurt event tomorrow. I'll be joining some peers from companies like T-Mobile, Swisscom, Novartis and SwissLife who are going to be sharing their own SOA success stories.

Why does SOA seem to be moving forward a little faster in Europe than in North America? We've posed these kinds of questions in our surveys and forums, and often it seems that stateside, the term "SOA" can polarize some IT teams - it's an "either/or" decision at the architectural level.

Talking to our EMEA director, Wilfred, he says part of the reason it seems adoption is high in Europe is that it SOA is often driven by developers working in smaller teams. Service-orientation can be started on a much smaller scale, and tested pragmatically before rollout to the larger organization. So, SOA there doesn't need to be an enterprise-level initiative in all cases, it can be something the company dabbles in before making a full commitment.

The upside of this pragmatic approach is that the SOA project can leverage some small wins to pay for a bigger commitment. The downside? Companies still need to beware of publishing services without a higher level of architectural coordination between teams.

This isn't to say that there aren't also companies in Europe starting from a strong enterprise architecture perspective and defining a top-down approach to SOA. I look forward to meeting both the pragmatists and the strategists this week!

Webinar on Service Oriented Virtualization

We have been doing so much with Virtualization in this blog that I have wondered if you guys are getting tired of it, yet almost every comment I get in person and most of the press requests are around the virtualization concepts for SOA.

And you know we've recently produced some new thinking on how to leverage all this with our Service Oriented Virtualization white paper and released major product enhancements to take advantage of these ideas called the LISA VSE (Virtual Services Environment).

To help put this in context we are producing a webinar with Theresa Lanowitz. Theresa has been a leading thinker in the ALM space for years and sees some of these same intersections between virtualization and SOA for tremendous value propositions. You wanna hear what Theresa has to say about virtualization and her thoughts on ALM 2.0.

Theresa and I are providing a webinar on SOV next Thursday. You can sign up here.

Service Oriented Virtualization White Paper

Well you’ve seen quite a bit in this blog already about virtualization concepts applied to SOA. Scroll down if you haven’t :) It’s a rare opportunity when cool technology makes perfect sense to help enable an initiative that has tremendous business value.

Virtualization up until this date has largely lived in the data center, where it has indeed saved significant hardware and configuration costs for a given set of servers. But this value has yet to extend to SOA, which is by nature much harder to replicate in this fashion. When you have so many distributed and heterogeneous technologies that are often not available for testing and development purposes, something needs to change to bring back that agility we expected from SOA.

We at iTKO are really excited about our contribution to leveraging virtualization in SOA. We call it Service Oriented Virtualization, or SOV. We do so because we are identifying challenges encountered by so many living in the SOA world and articulating a solution to those challenges by applying virtualization.

Please take a look at the SOV white paper. As always, I invite you to comment on the paper here. I would especially like to know how much you identify with the issues we raise and also how much you think that our solution will help.

Search SOA Articles

Rich Seeley, News Writer for the Search* Techtarget sites like Search SOA and Search Software Quality has been threatening his otherwise excellent track record by publishing interviews with me lately ;)

So as not to repeat myself here, you might want to check out the following:

SOA and REST, the interoperability conundrum (on a SOA vs. REST or WOA of sorts)
http://searchsoa.techtarget.com/qna/0,289202,sid26_gci1281171,00.html

A middle way to SOA governance ( A discussion on right-sizing SOA governance) http://searchsoa.techtarget.com/qna/0,289202,sid26_gci1281297,00.html

I've done a number of interviews with Rich over the past several months. One of the many take-aways I've had is that he seems to be right on the pulse of what's being discussed regarding things SOA. I highly recommend keeping up with his work.

SOA Business Process Validation

One of the primary goals of SOA is to model applications closer to the way that business processes actually function.

One way to define a business process is through a language called BPEL (Business Process Execution Language, or “Bee-Pill”) that allows us to create models using business-process type terms that would represent the actual system behavior in the backend of IT applications.

From a validation standpoint we try to take a simplistic approach--if we’re not careful--of trying to import these BPEL models as if they are tests of the processes themselves.

The problem with this approach is that it ignores the fact that testing is actually a verification of business or technical outcomes, not a defined procedure. What we have to do is cause the business process to happen – think of that as “Step One” of a business process validating test. But the remaining steps of the validation may have nothing to do with the business process steps as understood by the process model. Once a business process is in motion, you have to validate the expected technical outcomes of the process.

Let’s use an example: If placing an order within a SOA based application occurs by creating an xml document that represents that order and putting it on a message queue —let’s say that is the cause of a particular business process. Of course, the responsibility of that process as modeled in a BPM tool is to take the xml doc that represents the order and create the inventory transactions, create the shipping and order management transactions, update the CRM system and then close out the order or set the order status to some certain processed state.

How would we validate the business and technical outcomes of this process? Well it would start by causing that process to function. Step 1 then is to create that XML document and drop it on the queue. Great. Then what? Well this requires the an understanding of the outcomes, not the steps of the process. But let’s hope they help shed light on this...

We might have to check the system of record to confirm the order was placed. We might have to asynchronously listen on another message queue and interrogate the message payload for proper content to ensure the shipping system is properly instructed. We might have to refresh a web browser to prove that the end-to-end process completed in the acceptable amount of time.

Alas, very little of that is stored in BPEL :(

Then how can the business ever hope to validate thier business process models when the validation sounds like a bunch of bits and bytes? Ah, we have been working on that problem for years and have a elegant solution if I do say so. In another blog I’ll introduce the concepts and resist the urge to make it an iTKO LISA commercial.

iTKO LISA 4 Released, and here's my speech...

Warning: I'm taking a break from my usually pitch-free blogging to talk about our latest product release.
I tongue-in-cheek tell people that my day job is to run R&D for iTKO. It's true, but given that I am writing this blog on a flight that is day one of 6 weeks of covering the globe to discuss SOA Governance, Testing, and Validation with customers, prospects, conference attendees, and analysts, I think I need a better analogy than 'day job'...

Yet despite my inability to see my team face-to-face, my team continues to deliver an amazing amount of product enhancements; the latest release of LISA 4.0 is just another example of that.

We are always listening to customer feedback and incorporating changes. If you are an iTKO LISA user and have provided comments on a way we could improve our technology, I would bet most every one of you will be pleased to see your input reflected in this release.

And while we are certainly doing a significant amount of tactical improvements, we have delivered major improvements in one area and two whole new product capabilities unique to the market. See why I love these guys?

Load Testing: There is a product in the load testing area of our space that is quite dominant, and for good reason; it's a great product. In fact, many customers who adopted LISA for all their functional test and validation needs still kept this existing load testing product. We have been working with them to ensure that this is no longer required. Some still will and that's just great, but many will prefer to take that Collaborative 'C' to heart and perform all their testing from the same product.

LISA VSE: We have introduced the LISA Virtualized Service Environment, or VSE. Wow this is way more than just a new TLA. If you've been reading this blog long you know I'm all about leveraging virtualization for SOA. I'm working on a white paper with Jason English for publishing in the next few weeks on this, as it goes beyond what VSE does when you apply it as a business development practice. In short, it's a dramatic improvement in how teams can better decouple for agility and how to eliminate the contention on all those shared resources during design/dev/test time. I highly recommend you ask us what we are up to
here.

And finally, we have produced a technology for getting much better visibility into the transactional behavior of business processes we call Pathfinder. This is one of those see-it-to-believe-it things, so again, check it out.

Maybe the best part is we are so far from done I can't help but want to turn the plane around and start telling the guys what else to get started on....

SOA is still an immature technology pattern. Most teams I find are still struggling to get it right. And so much of what the market is still using are no more than repackaged traditional tools. No wonder it's harder than you think it should be ;)

Pardon the LISA commercial. You'll see I do very little of that in this blog. Yet I'm convinced that SOA is scary without LISA on the team. For those who can do the math on an ROI, you owe it to yourselves to check out the full-featured LISA 4 SOA Testing & Validation suite.

Virtualization and SOA – Part 4: Virtual Services

Last but not least of the three types of virtualization you might want to consider for SOA is Virtualized Services. I don’t mean virtualizing access to services as I mentioned in a previous blog, I mean simulating the service’s existence, without actually creating it. Now, how can that be important?

Virtualized Services are especially important to achieving the dream of agile SOA testing: shorter, iterative, requirement-driven test cycles, with testing happening every step of the way. Why? Because if you want to test earlier, you will need to test incomplete components, or “in progress” integrations. SOA applications are particularly prone to change, so if you have to wait for a finished app to test, that becomes a bottleneck to agility.

For instance our SOA testing product incorporates this approach. LISA has the ability to analyze a WSDL and to generate by itself the actual service endpoint. What this means is that before your development group has even shown up to build the actual service, our product virtualizes the service and creates a simulated version of the real thing (which doesn’t exist yet) – such that your consumers can invoke this service as if it already existed.

Now, in a simplistic world this can be done in a variety of ways with mock objects, or with other methods that provide a specific hard-coded response whenever they are stimulated. But in reality you are going to need a fairly dynamic service, even in a simulation. You can’t really spit back the same silly response to every single request, because your consumers are going to need a lot more richness and variability in the way that the service responds.

So, the ideal approach to SOA testing allows you to not only virtualize the service but to make the actual behavior of the service dynamic, i.e.: reading from database tables or spread sheets for values, or doing look-ups based on input requests. While it sounds like you are actually building the service (which in some ways you are), in reality you are providing just enough very high productivity logic within the service that you have virtualized so that the consumers get what they need without having to wait for the actual service to be completely developed and tested.

In fact, there’s a great “test first” model here, where developers of the actual service will know they’re done when tests written against the virtualized service work on the actual service. The consumers are confident that they will get what they need from the actual service when the virtualized service has been sufficiently executed against. And
with that virtualized service testing out of they way, you can now point the actual service consumer to the actual service producer, and therefore, likely have a much more successful integration from the very first touch.

I hope this series on Virtualization in SOA has been valuable, and feel free to ask me for clarification or more commentary on this or any other topic.

Part 3 of 4: Virtual Endpoints
Virtualization and SOA: Part 2 – Hardware Virtualization
An Intro to SOA and Virtualization: Part 1 of 4

SOA Virtualization Part 3 of 4: Virtual Endpoints

I been blogging on different ways virtualization as a concept is very helpful in the SOA world. The second such area is in virtualized access to services, called a Virtual Endpoint.

One of our SOA partners is Infravio, which is now a part of webMethods/SoftwareAG. As an example, these guys provide an ability to virtualize the access to a service, so that you create a looser coupling between your consumers and the service providers themselves. There are a number of upsides to this approach.

The first is: no one wants hard coded URLs from machine to machine within the client side of their applications. There is a lot of brittleness to creating such a tightly coupled system. As a service producer, I may need to start scaling up to multiple hardware devices or inter-clusters, or I may need to start creating geographically distributed servers to support the growing application consumption of my service over time. So, if my consumers become hard-wired into the actual location of my services, I create an inability to scale and adapt my service over time.

Virtualizing the access to a service thru an intermediary like Infravio gives me the ability to tell all the world to do UDDI lookup to my services, so instead of mapping to the actual service end points, the consumer can map to the intermediary.

The intermediary can then use runtime policy or infrastructure availability rules to determine which of the potential end points I actually deliver the request to. In doing this, I’m able to manage and model how I want my consumers to hit the services that I produce. I don’t have to provide unfettered access to all, I can actually put policy around how, how frequently, and when that access happens. I can even start to distribute it, such that consumers may not even realize that they are accessing the service now locally to their geography versus remotely last week.

As an SOA tester, I want this same level of flexibility in how we invoke and verify the behavioral and performance integrity of these services. By tying into UDDI repositories like Infravio, CentraSite, Systinet, etc. our SOA tests are dynamically pointed to the appropriate virtual service location, ensuring that the test workflow remains supported. This makes tests even more valuable and reusable, as they do not need to be re-wired for new locations as the systems are upgraded.

In addition, the service provider can specify a “test channel” or test version for their services, so a test can identify itself as such to the registry and be provided access to that specialized channel, in cases where simulated transactions may not cause the same effects as live transactions.

So, virtual endpoints are a great idea as you think about the scalability and the loose coupling we want in a SOA.

Virtualization and SOA: Part 2 – Hardware Virtualization

I mentioned in a previous article that there were three kinds of virtualization that a SOA practitioner would want to take a look at.

The first of these is Hardware Virtualization. We certainly like this technology, especially in a SOA, as this can help us with deployment efficiencies and versioning of services. The more that we can isolate the configurations for all the individual services running, the better.

It would be ideal if I could share one server-class machine among let's say 10 different services. But if I tried to put them all on one operating system, I inherently have configuration challenges due to the co-location of the services on one box. This creates challenges when different teams want the optimal environment for their service implementations. In fact there are some times when they are just downright mutually exclusive.

That’s where virtualization of hardware comes in. I still get that one server box, but within it I set up 10 different operating system installs on one physical infrastructure, and I am able to independently manage all of those different machines each having its own configuration. Let’s say that one service provider is running on Windows 2003 and another is running on Linux. I can run both operating systems on one physical device, without having to try to figure out how to get my teams to give up the rwar on operating systems. This is a perfect example of how we can get lots of leverage from virtualization of the hardware.

There’s another cool capability of hardware virtualization when I deploy a new version of service.
In a typical deployment of service updates:
- I have to change the code
- I have to change the configuration sometimes
- I might have to run database updates
- and these activities may basically take my service down for what could be long periods of time.

Clearly, all of the above might be a problem for my consumers. I can’t always schedule my outage times based on when all of my end users are okay with that. I may have global consumers – or not even know all my consumers. How could I possibly make updates given that there’s no particular safe time for that change.

Virtualization allows me to create a new virtual environment for the new version of that service, to configure it appropriately and to flip a switch by bringing down almost instantaneously the virtual machine that ran “version 1” of the service, and bring up immediately “version 2”. Furthermore, what if this “version 2” deployment just blew up on me? Rather than try to figure out how to uninstall the new version, un-configure the system changes and roll back my database changes, I can immediately revert back to the previous version of the service, if a deployment challenge arises.

Obviously as an SOA Testing provider, we find customers are able to move forward with a lot more confidence by validating their deployments using automated testing in conjunction with virtualized hardware. If the new configuration or build fails the battery of tests in production, the test fails and they simply roll back to the previous configuration, and treat the next configuration as a virtualized test bed for further refinement.

Having an “assembly line” of “as-was,” “as-is” and “to-be” versions as virtual configurations goes a long way toward reducing downtime due to rolling out, or rolling back new functionality based on the success or failure of both conventional acceptance testing, and automated testing of those virtual instances. We will discuss other aspects of virtualization and quality in future episodes of this report.

So, virtualizing the hardware provides us with a number of great upsides. These are just a couple of them. I whole-heartedly recommend that you think about services living in their own virtual environment on top of servers so that they are much more easily deployed and maintained at least in that regard.

An Intro to SOA and Virtualization: Part 1 of 4

I’ve been asked a number of times recently by industry peers and technology journalists about “virtualization” as it relates to SOA.

Well, there are in fact at least 3 distinct ways that you can use virtualization concepts in SOA, so I think that it would be good for me to give you a definition of those three, and then in the next few days I will blog on each one of them independently.

Rich Seeley recently interviewed me for a SearchWebServices.com article on the first and most often mentioned type of virtualization I’ll introduce -- which is hardware virtualization. This is not a SOA specific thing.  This is when you’re running many copies of the operating system within one physical hardware device so that you can get independence of those several virtual machines from each other -- from a configuration, app server and operating system point of view, but leveraging one piece of hardware to do that. I’m going to talk about why you do that in a future blog.

The second type of virtualization is virtual service end points. In a sense what you’re doing is creating a virtual location for your consumers to access in order to invoke the service when in fact you’re completely shielded from the actual end point of the service itself. So there is more disconnection between the consumer and the producer in that kind of virtual service end point. Again, I’ll tell you why you’d do something like that and what the pros and cons are on a future blog.

The third type is virtual services themselves: services that don’t actually exist -- you construct them without actually implementing them in a development tool.   Again, this type is separate from the other two types I’ve just introduced and has its own reason(s) to exist.  This is a powerful concept for managing the design and change cycles of SOA that I'll discuss soon.

So I hope you can get from this at least a basic idea of the three different kinds of virtualization you might be interested in with regards to SOA. Over the next couple of days we’ll take a look at what these are in a little more detail.

Practice Makes Less Perfect? Not with SOA Best Practices

I’m a professional, likely you are too. We’d like to think we get better at our discipline over time. Gartner’s Allie Young is predicting that this will not be the case.

Our practice, like many other professions, must adjust to the changing dynamics of our field of endeavor. For us, the increasing interconnectedness of SOA and SOA-like applications creates challenges that are not new to the readers of this blog but are in the market as a whole.

Due to these new dynamics, Ms. Young’s predictions include the following:
- Overall application downtime is expected to increase significantly, and that increase is expected to come from application errors (as opposed to infrastructure issues for example).
- Through 2011, 75% of all IT organizations will have quality problems predominantly due to silo-based suboptimization.

Here’s one time when I think it would be a good idea to let some professional pride get in the way of the status quo. My hope is that we can help so many customers achieve what Ms.Young called “holistic, integrated quality management” that the numbers actually improve over time. Call me a nut, but that’s why I spend so much of my time on the road with practitioners and in conduits like this blog.

I am convinced, and we have more data show every day, that adopting a set of best practices around our SOA Quality Three C’s and taking a practical look at SOA Governance will allow you to become one of those who Ms. Young says will actually be distinguishing themselves as the top-tier with their process, quality, and service improvement capabilities.

See, she left us an out. We can be the leaders and still keep her honest ;)

SOA Testing Best Practices: Complete, Collaborative, and Continuous

Fundamental to our thinking around SOA Testing best practices are what we call the Three ‘C’s: Complete, Collaborative, and Continuous. If you’ve heard a pitch or seen a webinar of mine surely this is not new to you. You can imagine, we have become collectors of stories of how important the three C’s are by listening to customer experiences of times when the lack of ‘C’ created vulnerability that was damaging to their business.

Here is such a story with enough of the actual details changed to protect identities. A software company testing lead related a story to me about what happened when they didn’t fully embrace the Complete ‘C’.

A new online software update site was produced for customers to buy new software and newer versions of their software. It was a SOA pilot and used web services as the middleware technology. Like so much of the conventional wisdom, they figured they would test the web UI with a record-and-playback tool and test the web services with another tool. After significant testing, they released…

Some three months later, a member of the ERP Order Management team asked this test lead ‘When are you guys going to go live with the on-line software site?’ Of course this freaked out our test lead because the site has been available for months but had apparently not generated a single invoice to a customer!

After urgent root cause analysis, it was discovered that the web service built to push orders into the ERP for invoicing queued the request but was failing to actually get the job done. Every OS patch and reboot caused them to loose all the orders that were captured!

This is the “verify” in our best practice around “invoke and verify” we talk so much about in the Complete ‘C’. We must be sure that the side affects we intend actually occur, otherwise we expose ourselves to unexpected issues that are almost impossible to detect.

This also highlights the need for Continuous testing in production. You know the issue could just as easily been that it worked during testing on the test ERP system but the production system requires account password refresh every 30 days; that fact unknown would cause the system to STOP taking orders quietly beginning our nightmare all over again.

To protect ourselves from these everyday events we need Complete testing on a Continuous basis, even in production when feasible.

Federated SOA Governance Whitepaper

With help from my colleague Jason English, iTKO has just pushed out a whitepaper on Federated SOA Governance. This paper includes a few concepts introduced first here on these blog entries but provides a great deal more context, not to mention Jason’s pretty pictures ;)

Read the new whitepaper here: http://www.itko.com/site/resources/whitepaper.jsp

Jason by the way is quite the Renaissance man. Being our VP of Corporate Marketing and an SOA Quality pundit in his own right should be enough, but add to that his brewery, singer/songwriter/musician talents, local political involvement, and the recent engagement to his beautiful and engaging fiancé, and I’m just amazed. Congrats Jason and Elena! Now back to our story.

“Federated” is a word we geeks use when we talk about data that distributed all over the organization, or what businesspeople try to do when they can’t tackle the whole problem themselves. Of course for those versed in US history, The Federalist or the Federalist Papers are all about how some of the founding fathers wanted us to understand the US Constitution. A significant theme was the proper restraint at the highest level of government and the delegation of much authority to those governmental organizations that were considered closer to the people.

The goal was to allow a freer form of self government than a super-sized federal government could provide but also enable that loosely coupled aggregate to behave with enough commonality that trade, communication, and consistency in the most important matters was still possible.

Much of the goal of “Federated SOA,” then, is to come up with an approach that can work around the conventional vertical hierarchies associated with company structures, and allow for “horizontal trust” between those underlying states, or departments, so they have the authority to act to fulfill their own operational needs, but the incentive to cooperate with other groups to fulfill common goals defined by the Federated SOA.

Gee, what a model for our comparatively simple SOAs! Smaller companies will achieve SOA success without the overhead of a federated system, but large companies and certainly inter-organizational SOA will likely not.

Thus the purpose for delivering this paper, and talking about how some of the mechanics of its workings should take shape. I hope you enjoy the read, and we always welcome comments.

The Big Difference Between Web Services and Full SOA Testing

We here at iTKO say all the time that there’s a big difference between web services and full SOA testing.

What do we mean by that? Usually we get that goofy blank stare because so many people equate web services with SOA and so from a testing point of view they equate the testing of web services with the testing of SOA.

While it is true that a number of initiatives for doing SOA are very web services centric, Aberdeen’s last research on this points out that only about 50% of the SOA initiatives at large companies are web services based. There are a variety of technologies being used to create that commoditized middleware for SOA. While we love web services for this, other technologies are very valid, possibly better for a given organization than a web services stack. I’ll maybe spend some time blogging on that topic later.

The biggest difference between web services testing and full SOA testing, even for a web services shop, is the concept of testing implementation and side-effects as opposed to just the middleware layer.

Let me give you a scenario:
Let’s say that you are trying to test the functionality of a web service that encapsulates two or three different systems, and provides one façade for those three systems back to a potential service consumer -- this is a really good use of web services. So, you have a web services testing tool invoke web services and get payloads back in the form of SOAP XML docs. Now let’s say you get something back that doesn’t look right. Where’s the problem?

• Is it in the web services stack?
  
• Is it in the implementation of that wrapper?
  
• Is it in the implementation of one of the three underlying services?
  
• Or, is it in the interaction among those three components, (four when you include the web service itself)?
  

Without complete heterogeneous testing of all of the components involved in the SOA, you’re never going to know the root cause of the problem. That is the huge distinction between the ability to test a real SOA implementation vs. the ability to do WSDL/SOAP testing of Web Services alone.

Here’s an example of how this plays out in the real world:

I was with a prospect a few months ago and going down a path somewhat similar to this with them, when someone just jumped right out of the blue and said:
“You know I had a situation just like that -- I’m a tester and I brought a SOAP document to one of my developers and said: Hey, I believe that this proves that there’s something wrong with the service.”

The developer took one look at that XML document and said, “This doesn’t resemble anything I do.”

While that kind of brush-off might not be warranted, the developer has a point. Our tendency is to suspect the validity of the indirect vs. proof that is directly connected to the implementation. In order to really help that developer see what’s going on in his or her own component, we needed to see a test of their implementation directly.

We’ve got to test as close to the implementation as possible because that’s where the bug is. We don’t want to test indirectly. Other moving parts of the environment will cloud our visibility into the root cause and tend to blame the wrong things. It sounds like UI testing all over again only instead of a user interface, we’re using a web services interface that hides the business logic as it is programmed.

Hopefully I’ve given you some insight on one of the many differences in fact there are between web services testing and SOA testing.

SOA CoE PDQ

If you built a CoE (Center of Excellence), every time an analyst told you to, there’d be more CoE’s than there were desks in the IT Dept. But of all the areas where a CoE might be most critical, an enterprise-wide SOA initiative would be one of them.

In most organizations, vertical trust up and down the chain of command is relatively easy to come by and already exists. The line of reporting structure typically creates the sense of reuse, standardization, and the ability to leverage vertically within an organization.

But at the highest levels, horizontally across peer groups, that is usually not the case. Ironically, a lot of organizations I’ve seen tend to foster distrust and create an anti-collaboration spirit between those horizontal peer groups. We’ll have to resolve this for SOA to work. That is why creating horizontal trust is such a critical aspect to SOA adoption.

Grossly generalizing, when bad things happen within an organization vertically, the thinking is ‘hey we’re in this together so let’s work it out’. That same issue occurring across an organization horizontally would more likely sound like ‘those guys are morons -- I’m not going to make the mistake of relying on them again!’…

One of the ways that it’s possible to combat that trust concern, and instill a sense of trust, is through a center of excellence around SOA. To instill trust horizontally and make SOA adoption possible, we need to use an analogy from a States’ rights vs. Federal rights debate. The individual divisions need to consider themselves autonomous on certain levels, and bestowing certain rights to the Federal level; but they also have the opportunity to participate at that Federal level, so that it isn’t just a “Down from Above” edict that will immediately create a defensive reaction instead of an embrace.

So, if we think about what the SOA CoE must look like then, certainly there needs to be a set of participants that are not beholden to any particular one of the divisions involved, but there also needs to be significant membership from all of those who will be involved so that we get the participation – this isn’t US vs. THEM – this SOA CoE is a self-governing model.

This organization will model what policies need to be so-called Federal Policies and which can safely be handled at the State level. For example, we talk about policy that can be automated along the three domains: structural, behavioral, and performance. It might be quite accurate to say that at the Federal level, structural policy (or compliance) might be the most important aspect, while from a State-to-State kind of policy, behavioral and performance policies will perhaps be most important to define at those levels.

Take that one step further: SOA Governance needs to be explicit about how to publish a service, and precisely what is involved in consuming an existing service. Whether it’s within the same division or across divisions, the behavior and performance policies need to be authored, automated and enforced.

I hope this has made some sense in that without this kind of CoE, we are in a very difficult position when we are trying to create that horizontal trust. We must create a better way to provide SOA visibility across the organization, which is historically not very easy to do.

Consumption is NOT Free

I recently blogged on the topic of an SOA marketplace dynamic that I believe will take shape over the next many years. It reminded me that I never have articulated my case for the fact that consumption of services is not free, so it shouldn’t be free.

Here’s what I mean: If I create a service for my own internal use, the certification effort (the level of structural, behavioral, and performance policy) will not be nearly as high. Over time my maintenance of that service will be much lower. There will be much less risk in changing that service when I have a well known, finite set of consumers that are under my control as opposed to a broadly leveraged service that will have a widely distributed use among lots of folks that I’m not even aware of.

All of this contributes to an increased cost of producing a service that is robust over time and reusable. So for the producer, consuming the service is not free. Given that, the consumption itself should not be free. There must be a reckoning of some sort when a project team gets the benefit of an existing reusable service that is properly maintained and therefore increased in its own cost for doing so. That reckoning has to occur and if it doesn’t either one of two things occur:

• Either we penalize the production of robust services and, therefore, we don’t get as many--
  
• Or we produce reusable services that will die on the vine as it were.
  

The increased burden without an associated increase in the budget for that service to be reused will actually threaten that service’s long term quality and adherence to policy.

So in the end, consumption of existing services does have a net decreasing effect on the cost and time of producing a solution. We’ve got to love that – but we can’t ignore the fact that it doesn’t come without cost even if it is less, much less than building from scratch.

All this means consumption isn’t free.

Governance Tools -- Buyers Beware

Enterprise software has a sometimes-sordid history of greatly over-promising and under-delivering. Some vendors I see in the governance space for SOA are repeating that bad history. That’s unfortunate given the tremendous promise in SOA and the tremendous capabilities that are possible for SOA governance.

No one vendor, even my own company iTKO, can provide 100% of what I would think is a robust governance solution today. It may never be that one vendor delivers 100% of a governance solution. Yet I’ve just been reading many vendors talk about their complete robust end-all-be-all governance solution for SOA.

While several vendors have a fairly common definition of a Governance, it’s entirely too inadequate to really suffice for a complete, robust, or end-all-be-all solution. In fact most Governance solutions right now in SOA are little more than bundling WSI tools and scanning XML with Xpath queries at run time for automation, and document repositories for non-automated Governance.

This is barely the beginning of what will create real governance. The outcome of a robust governance strategy is increased visibility, trust, and an infrastructure that has longevity compared to the many times we’ve attempted greater reuse and better IT alignment with the business.

One of the key areas that my company focuses on around governance is in the behavioral area and in making the definition of the word “policy” more rigorous than the meanings frequently used by the so-called governance tools also in our space.

At the end of the day, policy will need to be all of the kinds of things that you think of legislatures doing or any kind of rule-making body in our real world. Think about at the Federal level, very broad stroke kind of Policies. These are the things that some governance tools can do like “Thou shall use WS security for all of the access points from external sources coming on to our network. But there is also the State level, County level, City level and even Home Owners’ Association, if you think about it. You will never see a Federal Law about where I’m allowed or not allowed to place my US flag. But my Homeowners’ Association has all kinds of rules and restrictions about where I can and can’t place my flag.

So policy is really going to be where we, as an industry, focus Governance tools and within that focus, we’ve got to make sure that our definition of policy captures enough of the “what it takes” to get the value from Governance.

So the next time you are talking to a Governance tool vendor, let me suggest two things:

The first is to make them fully explain themselves about what their product does in terms of allowing the definition, modeling and enforcement of governance policy.

And, second, don’t just listen – make them show you.

We have a customer that spent 7 figures on a tool that was supposed to do a bunch of really interesting policy and governance work that’s barely doing much of that at all. You’ve got to see how the product works.

Governance buyers beware.

Global SOA - Quality = A World of Trouble?

We have a customer who was a highly advanced and ambitious early adopter of Services-based applications. Prior to adopting some of our best practices and our product for continuous testing, they had come to the point where their Services Group (a shared services team that was the producer of a set of services for an entire division of a company) had to go to an annual release basis.

Much worse, because of the fact that there were so many applications built on top of the shared services platform, and they were so distributed globally, they really couldn’t keep their hands around everyone’s use of these shared services.

They had to make a hard stop on November 1^st of every year, and go into a 6-week procedural test cycle, where any failure anywhere within the entire division would stop the rest of the division from being able to complete the test cycle. And, upon completion (hopefully in that six weeks) to find what could run for that month’s test cycle, finally release all the upgrades to not only the shared services that were built that year, but all of the applications that were depending upon that shared services platform.

Now, hopefully, that gives you some insight into what happens when you try to go to a services approach, but you don’t marry it with very rigorous and continuous automated testing. At the heart of the matter for these guys, SOA lifecycle quality was the missing piece. When you have a shared set of services being leveraged by a variety of consumers across the globe, the changes that are seemingly irrelevant almost, at the shared services level, can have a catastrophic effect on the applications that depend upon them. The worst part is that the developers of those shared services may not even be aware of the potential catastrophic effects of their application cycles on the service consumers.

All it takes is once or twice of having those unintended consequences show up as huge performance issues, or as huge production outages, or, my worst nightmare, actual bad functional integrity where the business is actually getting the wrong answers (I don’t mind slow answers or no answers -- but wrong answers are worse). No one is sitting with a calculator beside their computer verifying all of the transactions that the system is doing. So if the global system is doing them wrong -- you are in a world of trouble.

So what they had to do was coordinate the release of every one of these applications within this very large division of a large company. With our solution, taking some good SOA best practices, and using LISA from a continuous testing/continuous integration kind of basis, they are now going to be able to start dismantling this annual release cycle. As they increase the level of automated coverage of shared services and of the applications that depend on them; they have the freedom to change without the unintended consequences catching them off-guard.

So, in a nutshell, continuous SOA Lifecycle Quality testing to prove functional integrity has huge returns for the business. They see the value of going from an annual Big Bang release, to more quarterly releases, then monthly releases or “as needed” releases so that they can realize the agility they expected from SOA, with the reliability required for business. John Michelsen, Founder and Chief Architect, iTKO

Your SOA Governance Policy Isn't Big Enough

As we continue to mature the SOA Governance space, the Policy area appears to be the one that is the most immature.

Vendors that are focused on Policy have a big, big job ahead of them. In fact, we believe that the Registry/Repository area and the Testing area of governance will have a lot to do with policy definition and enforcement in addition to those tools that are called governance policy products.

The reason is because policy is a VBT (Very Big Thing). In fact, I think 3 years from now governance will really just be defined by policies and in so doing it will take all three aspects of governance to make policy work.

A simple example -- today’s Policy typically sounds like:

• “Interoperability checks”
• “ws-security verification”
• “Hit testing on XML documents (for you bit twisters like me)”

Pretty granular stuff. That’s not a very big policy.

In fact, the business won’t want to mandate policy that has much to do with things in XML and what standards you’re using. Of course they want standards to get the reuse and interoperability, but their version of policy will be:

• “I really need functional integrity on this particular transaction activity of the system”
• “I really need customer credit checks to always be accurate to within 30 minutes of the customer’s activity.”
• “I can’t allow stale data to be reported as customer’s current activity.”

All of these kinds of things – that’s Policy.

When the business talks about policy, they are not going to read standards definitions from OASIS. They are going to talk about what their business functions are and what kind of expectations they want to put on the systems that are implementing those policies. That is Policy – that is a Very Big Thing.

So, short and sweet, if you are talking to a vendor who has got a so-called complete SOA Governance Policy Management System -- I haven’t yet seen that thing. Their definition of Policy is way too small.

You’re going to have to sign off on the much bigger problem of Policy at the business level, which is what SOA should be all about. Remember, we are aligning IT to the business, but not if we force-feed a definition of Policy to business. Business will take on a "free-market definition" of SOA Policy, whatever the consortiums try to dictate.

When the definition of policy is business-aligned it’s going to require very rigorous, here’s the bad word, “TESTING” -- on a continuous basis of the functional integrity of the system as it is running. Of course, things like IT guidelines are good policy, Performance Expectations are good policy, Down Time and Notification and all of those other things, very good policy. But if it isn’t also heavily involved in the way the business wants to set up expected behaviors, it’s not big enough.

-- John Michelsen, Founder and Chief Architect, iTKO

Web 2.0 versus SOA?

WeB 2.0 versus SOA? So I’m reading Blogs -- which is suspect to begin with because I’m sure there’s just a bunch of random content out there in the blog world right? And, I run across several Blogs on Web 2.0 versus SOA”.

Let me tell you friends -- if someone is trying to pit Web 2.0 versus SOA they either don’t understand Web 2.0, they don’t understand SOA or both. I thought Joe McKendrick did a good job of describing the irrelevance of this argument as far as CTOs are concerned in Another view: A CTO underwhelmed by SOA,.

It’s complementary to SOA, which is a way to establish the decomposition of business logic to establish service-based workflows--to break apart monolithic systems into services such that collaboration among services is more rapid and more agile.

So what you can accomplish with Web 2.0 is synergistic with what you can do with SOA. By the way, don’t misread this and therefore presume that SOA requires Web 2.0.(because that Blog, I am sure will be the next Blog I see if I go Googling a little bit more) and that’s not correct either.

You can build SOA with C code and Windows Client UI written in VB if you wish. The goal here is to try to establish a little more sanity in what these things actually are. Web 2.0 is a great way to put a thin client yet interactive user experience on the desktop. SOA is a great way to go about the process of decomposing systems into services and making business alignments through business process management.
- John Michelsen, founder and Chief Architect, iTKO LISA