Death of Custom Software Development

(Disclaimer: This post is largely based on an excerpt from my contribution to the upcoming book from Thomas Erl's Service-Oriented Computing series, Next Generation SOA: A Real-World Guide to Modern Service-Oriented Computing.)

Until very recently, the typical approach for many corporate IT departments when dealing with a business problem has been – code first, ask questions later.  Many enterprise systems have been custom coded in the past.  But this trend is changing.  Companies realize that biggest value is gained from leveraging existing vendor or cloud-based solutions and integrating them into useful business solutions. 

The transformation from a development to integration mentality moves companies up the maturity curve significantly.  Agility is gained by purchasing or leasing the necessary foundational capabilities and customizing them to meet business needs.  IT no longer spends majority of its time building solutions, finding bugs, and deciding which SDLC is better.  Instead, IT teams can concentrate on delivering business value.

Organizations that adopted the integration first mentality are also forced to determine their competitive advantage strategies.  Michael Porter identified three types of business capabilities that should be considered in designing a business strategy.  They are base, competitive and differentiated capabilities.  Base capability is one that is foundational to the business, without which a business cannot operate.  This includes accounting, finance, HR, etc. as well as basic customer facing capabilities that are taken for granted.  Competitive capabilities are those that allow companies to remain competitive with each other.  For example, banks typically match each other’s lending products, interest rates, depository vehicles, etc.  Differentiated capabilities allow companies to stand out and separate themselves from each other.  In banking, examples of this include bill pay features, innovative product offerings, customer service, etc.  Michael Porter argued that companies want to be as good and efficient as its competitors in the base and competitive capabilities, but they want to excel in the differentiated capabilities to win.  Investment strategies should also match this philosophy.  Minimal necessary investments should be made in base and competitive capabilities that allow businesses to remain on par with others, but maximum possible investment should be made into increasing the degree of differentiation.

IT investment strategies should match those of its business partners.  Therefore, IT should consider which capabilities its investments support.  Just as with the business side, IT should minimize its spending on base and competitive capabilities and maximize spending to support differentiation.  The coding and integration strategies are also impacted by these decisions.  While base and competitive capabilities should almost never be custom coded, differentiated capabilities can, and oftentimes, should be.  In the modern world, however, custom development most often takes shape of configuration or scripting, as in business process design, business rules development, and vendor package configurations.  Little room is left to coding new functionality from scratch.

Service-orientation becomes a significant factor when companies adopt an integration mindset.  It becomes the central theme of everything that happens within an enterprise.  IT assets become a loosely coupled collection of vendor products, SaaS, services, mashups, and legacy applications.  Service-oriented middleware and SOA governance become key players in every project, initiative, and program.

Finally, the company’s entire culture must change.  Everyone, from business and IT leadership to sales people and developers, must embrace the integration first mentality. Without it, there will constant infighting between the development and integration clans.  Philosophical battles will ensue.  But if clear direction is given to the organization and business and IT stand shoulder to shoulder, there will be very little choice but to accept the change.

One CIO I worked for issued a very clear and concise statement of direction to his IT organization related to software development decision criteria: "Reuse before buy before build."  Everyone understood and embraced it.  The IT organization understood what decisions took priority over others.  Business stakeholders started asking questions like "Are there software assets we can reuse for this effort?" and "What vendor solutions exist for this problem?"  The entire organization adopted the integration first mentality as a result of the CIO's guidance.

While software development will never completely disappear, most IT organizations supporting mature businesses need to shift towards the integration first culture.  Let's face it, IT groups are not in the business of software development -- they are in business of supporting their business.  IT needs to concentrate on delivering business value, not building custom software!

Business Process Excellence for Financial Services 2011 Conference

I will be presenting two sessions at the IQPC Business Process Excellence for Financial Services 2011 conference. The first one is a pre-conference workshop on Service Oriented Architecture And Business Process Management: A Comprehensive Approach To Business Performance. The second one is the first session of Day 1, Embracing Truly Integrated BPM: A Holistic Approach. This should be very exciting!

SOA & Cloud Symposium Podcast

SOA and Cloud Symposium podcast published. Listen to it at http://soasymposium.com/podcast2011.php. This podcast is part of the International SOA and Cloud Symposium Conference Series and the upcoming SOA Governance (Prentice Hall Service-Oriented Computing Series from Thomas Erl) book launch.

SOA Misconceptions

I continue to see a number of common misconceptions about SOA. There have been a number of articles written about this when SOA was first introduced. They primarily concentrated on dispelling the myths that SOA = Web Services. Current misconceptions run deeper and a lot more general.

1. SOA is Expensive
SOA doesn't have to expensive. There is an abundance of open source tools and technologies that can be used to build a truly state of the art SOA platform.

2. SOA is Inefficient
SOA is as inefficient as you make it. Not all the problems and organizations require a complete SOA stack but, at a certain level, it becomes necessary. Otherwise, you will have too much complexity and, in fact, breed inefficiency.

3. SOA is Non-productive
A well established SOA program can run like a well-oiled machine. I am sure a lot of people can cite numerous examples of lost productivity because of unnecessarily complex SOA environments and processes. However, in large and complex corporate IT departments well defined organizational structures and processes are a must. They actually make things more efficient and increase productivity. Every situation requires a different approach. However, SOA, as a general pattern for building software, has been shown to dramatically improve productivity. Think about it -- if several projects can reuse an already existing, well tested service, this results in tremendous productivity improvements and costs savings!

4. SOA is Unnecessary
This is true, with a caveat. SOA has been employed as an IT and business strategy to make organizations more efficient, productive, and agile. If you want your company to achieve these goals, SOA becomes a part of the answer. Otherwise, you are stuck in the world of point-to-point integrations, Just a Bunch of Services, and an unmitigated integration mess in general. Obviously, smaller companies can get away without employing SOA for a much longer period of time but larger ones will feel the pain much sooner.

5. SOA is Too Complicated
Yes, SOA is complicated. But what major effort isn't? Enterprise Architecture is complex, so we shouldn't do it?! EAI was complex but companies did it out of necessity. Master Data Management is complex, so companies should forget about managing their data?! SOA can be as simple or complex as you need to make it. Create a roadmap for your SOA program and follow it. It should guide you in your quest to achieve SOA maturity, however simple or complex you need to make it.

SOA is a program. You can make it into whatever you need. You can use whatever technologies and approaches you like. As long as you keep the goal of increasing agility and saving money as a result of creating reusable business capabilities in mind, you should be successful.

SOA and the Trough of Disillusionment

All the signs point to the fact that SOA has entered the trough of disillusionment. Why? I am seeing a lot of companies de-funding or stopping SOA efforts altogether. Many executives don't see the hype anymore and thus no longer understand the value of SOA. Many companies have tried SOA and failed, so they don't want to try it again. Plus, the economy is not helping. Budgets are getting slashed, jobs are lost, people are afraid to innovate. The first type of spending that companies cut is strategic. They want to get through the tough economic times with minimal required spending -- just to keep the lights on. Thus, SOA program funding gets cut and the executive support goes downhill with it.

What can we do to make sure that SOA moves onto the slope of enlightenment and further to the plateau of productivity? Continue to educate your organizations and executives about the value of SOA! Even though SOA is not in vogue anymore, it doesn’t mean that it lost its value. The benefits are still there. You just have to work harder to make them visible. Document your successes and shift into a marketing mode. Promote the SOA program and the benefits you achieved as much as possible. Show real value. This will certainly get executives’ attention and guarantee their support. Don’t give up. Continue to fight negative perceptions and concentrate on delivering value.

SOA, like any other enterprise wide initiative, is a differentiator. Companies that can successfully implement SOA will become a lot more successful than those that can’t. When the economic crisis ends, organizations that continued to invest into SOA will come out on top. Those that didn’t will be left behind and will need to spend a lot more money and efforts to catch up. SOA can produce tangible business benefits. Don’t let the disillusioned minority silence its value proposition.

SOA Funding Models

One of the primary reasons SOA efforts fail in many companies is simply due to inadequate or inappropriate funding models. Costs are typically at the core of every problem and SOA programs are not exempt. We hear horror stories all the time – the initial investment to establish an SOA environment was too high, so the effort was cancelled; there are many services created in the company but they are hardly reused; etc. Establishing a funding model that is right for your company is the key to moving the SOA program forward.

Any SOA initiative is comprised of two parts – infrastructure and services. Both need to have a separate funding model established in order to successfully support SOA program’s goals.

SOA Infrastructure Funding

Infrastructure funding requires a pretty straight forward approach. When discussing SOA infrastructure, I am referring to shared platforms that are used by a number of services across the organization. Some companies host services on the same platforms whose functionality is being exposed. However, even if this is the case, some shared infrastructure components like ESBs, service management technology, Registry/Repository, etc. must exist to support SOA program’s needs. Thus, it is safe to assume that some form of shared SOA infrastructure exists. There are two possible ways to provide effective funding to build it out.

1. Fund all the SOA infrastructure centrally
2. Identify appropriate projects to acquire / extend new / existing SOA infrastructure

Central funding is probably the easiest and most effective approach. It allows the organizations to establish an independent roadmap for introducing and upgrading SOA infrastructure. It also makes the SOA program operate more efficiently as the cost, scaling, and availability issues will no longer be relevant to individual projects. If central funding option is selected, several approaches for recouping the initial and ongoing investment can be utilized.

• Do not recoup the investment
• Place an entry fee to use any SOA infrastructure component
• Charge a small fee for each usage instance

Since all the SOA infrastructure is provided centrally, not recouping the initial investment is a real option. If the organization’s fiscal model does not call for IT recouping all its costs from the business groups using their products, this option works well. If this is not the case, however, you have a choice between placing a predefined entry fee that each application / project must pay to use the specific SOA infrastructure platform and charging end users based on the total usage.

The per-use-fee scenario is a little tricky as each SOA infrastructure component needs to define what a transactional unit is and how much to charge for it. Transactional units can be different for each SOA platform. For example, an ESB transactional unit can be a service call, Registry/Repository – an individual user and/or a UDDI request, etc. In this case, total usage amount based on predefined transactional units would be calculated, multiplied by the unit cost, and charged to the business units. The most effective way to determine a unit cost is to divide the total investment made in the platform by the total transactional units being consumed. The obvious effect is that unit costs would decrease with increased usage. Here are all the formulae discussed above.

Usage charges per platform:
Unit = Different per Platform
Unit Cost = Total Platform Investment / Total Amount of Units Consumed
Line of Business Usage = Units Used by Line of Business * Unit Cost

Some companies have chosen to grow their SOA infrastructure gradually, without a central program or funding. A typical approach in this scenario has been to attach SOA spending to the most appropriate projects. Thus, the projects would purchase new SOA infrastructure platforms or upgrade existing ones to suit their needs. There are several problems with this approach.

1. Typically, the projects purchasing the infrastructure don’t want to share it with other potential consumers unless there is significant pressure from above. The platforms don’t end up being reused or, if so, only minimally. The projects do not have any incentive to sharing their investments with anyone else, especially since they are seen as critical to projects’ success.
2. Projects often get cancelled due to over-inflated budgets. SOA infrastructure is expensive and cost conscious enterprises do not want to invest into what looks like excessive infrastructure for project’s needs.
3. Demand to extend a platform based on project’s needs typically comes without enough lead time to accommodate project’s timelines. Thus, projects face a tough decision – to extend their delivery date or use alternative infrastructure.

Funding the SOA infrastructure centrally is more effective in delivering service-oriented solutions faster, moving the enterprise more efficiently towards a higher level of SOA maturity, and addressing the project needs. Project-based funding will most likely spell doom to the SOA program as a whole.

Service Funding

As discussed earlier, funding for the SOA infrastructure should come from a central source. Where the money comes to build individual services, however, presents a bigger challenge. Since projects are the primary drivers behind demand for services, special consideration should be given to project needs and budgets. However, service design and implementation can incorporate additional requirements that fall outside of the project scope. Another typical project-related problem stems from the shared nature of services. It is unfair to burden a project with the full cost of a service that will be utilized by a number of other consumers.

There are three possible ways to address the service funding concerns.

1. Make the first project to build a service provide the complete funding
2. Establish a central funding source that will cover all service design and construction expenses
3. Provide supplementary funding to projects building services

If option1 is selected, several strategies for recouping the initial investment can be used.

• Do not recoup the investment
• Place a surcharge on each instance of service leverage
• Charge a small fee for each service call

As mentioned above, it is unfair for the project to carry the complete costs of the service build-out, especially if it includes additional requirements. Thus, unless the project implements one of the options to recoup its initial investment, funding option #1 is not going to be viable. Not recovering the funds is not a realistic option either as it does not incent the projects to build truly reusable services. The other cost recovery strategies may work but require detailed metrics to be captured on the service leverage and/or transactional volume.

Establishing a central funding source for all projects to use when building reusable services is probably the ideal approach. Few companies, however, would be willing to write what in essence would be a blank check for the projects to use in their service delivery efforts. The opportunity for abuse and misappropriations would be too tempting. Unless strong governance and control mechanisms are in place, this funding method will most likely end up costing the company more money and provide unrealistically small return on investment.

Providing supplementary funding to projects building services is probably the most realistic approach. A central fund needs to be established to cover the efforts falling outside of the project scope. Since shared services would typically incorporate other projects’ and enterprise requirements, the actual cost ends up being higher than what projects budgeted for their needs. Thus, the easiest way to distribute supplementary funding is to allow the projects to pay for functionality already included in their budgets and cover all the additional costs through the central fund.

Whatever the funding approach is used, it needs to be carefully administered. A party not involved in day-to-day project work is best suited to play the administrative role. There could be a couple different groups managing the infrastructure and service funding and chargeback mechanisms. Overall, however, this should fall under the SOA Governance umbrella and managed centrally as part of the SOA Program.

Making SOA ROI Real

Read the "Making SOA ROI Real" article published in the SOA World Magazine.

http://xml.sys-con.com/node/847118

Service Orchestration Guidelines

Many SOA articles, white papers, and vendor documents talk about “service orchestration”. But understanding of the underlying concepts and orchestration best practices remain elusive.

A quick Google search will produce a number of articles and links that discuss service orchestration and related topics. Most of them will talk about BPM engines, ESBs, and BPEL. This, unfortunately, pollutes the true definition of service orchestration and gives it a much more technology centric view.

In my opinion, Service Orchestration is an automated way to combine several services together to achieve new functionality. The end result is a new composite service that provides a distinct business capability and can be invoked independently. It must have all the appropriate attributes as discussed in my previous article.

Orchestration is a technology independent concept. It can be achieved via a descriptive language such as BPEL, built-in tools within a specific platform (ESBs typically provide their own orchestration mechanisms), or programmatically. Depending on your needs, situation, or technology available, the best way to perform service orchestration may be different. Here are a few guidelines to help you create service orchestrations faster and make them more flexible, maintainable, and scalable.

• Use the platform with built-in orchestration capabilities as your first choice
• Avoid implementing service orchestrations programmatically whenever possible
• Choose a platform or mechanism that can easily perform flow logic, result aggregation, message transformation, and business rule application
• Ensure the composite service fits the definition of a service, i.e. has all the attributes of a service

The rationale behind the above guidelines is very simple. You want to choose a platform that already provides most of the capabilities you will need when creating new service orchestrations. You will typically need to call several services, aggregate their results in some way or chain the calls together through some kind of logic, transform the end result to match the exposed contract(s), and return it. The less work you have to do and the more you can rely on the platform’s capabilities, the more efficient your orchestration will be. If you can complete your orchestration work through a visual interface and never see the code, you are on the right path. This way, you will spend less time maintaining the orchestration, it will be easier to make changes, and you don’t have to build all the necessary mechanisms from scratch.

Many would argue that a programming language will give you the most flexibility when implementing an orchestration. While this is true, the overhead is pretty large and efficiency is low. First of all, no programming language seamlessly integrates all the mechanism you need to create an orchestration, especially in a visual way. Secondly, every time an orchestration needs to change in some way, no matter how small, new code needs to be written, deployed, and tested. While the same steps need to be performed on any orchestration platform, the level of effort will be a lot smaller on full featured orchestration platforms.

When creating service orchestrations, it is important to maintain proper relationships between composite and atomic services. The diagram below shows which services should be allowed to interact with each other.

The following list details the rules and guidelines for establishing relationships between composite and atomic services.

1. Atomic business services should not call each other. Use orchestration to combine several business services together.
   The goal of service orchestration is to combine several services together through a series of logical steps and expose new capability to the consumers. Orchestration platforms, as discussed above, provide a lot of functionality to make this work easy and efficient. If individual services are allowed to call each other, they would not be taking advantage of the orchestration platform’s capabilities. Furthermore, when business services call each other, it establishes a tight coupling between them, which makes them less reusable and harder to maintain. Atomic business services should provide specific, well defined business capabilities and be reusable in their own right. Reliance on other services to complete work indicates plurality of purpose and lack of specificity.
   
2. Business services can call Utility services.
   While coupling services together should be avoided as much as possible, sometimes generic, low level functionality that needs to be invoked from a business service is exposed via utility services. It would be an overkill and sometimes even impossible to use an orchestration platform in order to allow business services to take advantage of such functionality as logging, retrieving or storing configuration information, and authorization.
   
3. Utility services cannot call Business services.
   Utility services should not be tied to any business processes or capabilities. Thus, a utility service calling a business service would violate this rule.
   
4. Business services cannot call Composite services.
   The logic behind this guideline is the same as in disallowing business services call each other. A composite service is also a business service. Thus, a business service calling a composite service should not be allowed.
   
5. Composite services can call other Composite services.
   Other composite services are allowed to participate in orchestrations. They should be treated as regular atomic services in this case.

Note that, even though atomic business services and composite services are, in essence, business services, they are different and guidelines provided above are not contradictory in their treatment. There are two levels at which they should be compared -- logical and physical. From a logical perspective, atomic business services and composite services are the same. They expose some kind of unique business capability and adhere to the service definition guidelines. From a physical perspective, however, they are different. Atomic business services, as opposed to composite services, rely solely on internal business logic and direct interaction with backend data sources to perform their work. Thus, by definition, atomic business services should not call other business services as part of their implementation. By the same token, since composite services already rely on other business services to complete their work, they should not differentiate between calling atomic business services or other composite services.

Service orchestration is a complex topic and might take a series of articles to discuss completely. However, the rules outlined above should establish a good foundation for creating and managing composite services.

Services Explained

Since the SOA term was coined, many discussions raged on what a service was from a business and technical perspectives. In this article, I offer my views on the topic.

There are several categories of services. Many leading SOA vendors and thinkers typically break them down into Business and Utility types. A Business service represents a business capability that is needed to complete a step within a larger business process. Examples may include retrieving customer information, making payments, or checking order status. Utility services represent a technical capability that is business process agnostic. Examples are e-mail, logging, or authentication services.

Services can be combined together to create composite services. This is called orchestration. An example of this can be a Money Transfer service that needs to debit one account and deposit money into another one. Composite services can also be categorized as Business and Utility. Best practices and general orchestration guidelines as related to orchestrations, atomic services, and their relationships will be discussed separately.

Regardless of the type, a service is comprised of three components.

• Interface
• This defines how services are exposed and can be accessed by its consumers.
• Interfaces are not limited to Web Services and can be represented by any remote messaging protocol.
• Contract
• This defines what services expect during the interaction with the consumer. Message structures, relevant policies, and related security mechanisms are all part of a contract.
• Contract defines a “legal” agreement on how the service and its consumers should interact.
• Implementation
  
  • This is the actual service code.

A service may have multiple interfaces. Different consumers may have the need to access the service via different protocols. For example, a Java consumer would like to access a service via a Web Service protocol while a Mainframe application can only use MQ Series. Even though a service may itself expose multiple interfaces, it is more effective to let the ESB platform handle this. For more details about the rationale behind this recommendation, see “To ESB or Not to ESB?" post.

A service may also have multiple contracts. I have recommended in the past that for a service to be maximally reusable, it needs to implement the Service Façade pattern (see “SOA Façade Pattern” post and “Service Façade” pattern). This pattern recommends that multiple different interfaces and contracts for the same service be created. The Concurrent Contracts pattern also addresses this issue.

It is important to understand that while the interface, contract, and implementation describe a service as a whole, they are not closely tied together. An interface is not dependent on the contract details and should not be tied to the specific messaging structure. The opposite is also true – the contract should not be tied to any specific communication protocols. Additionally, the implementation should be flexible enough to accommodate the potential for multiple interfaces and contracts. Ideally, however, I would recommend that a service expose only a single contract and interface and the ESB would take care of exposing additional endpoints and facades as necessary.

EA & SOA in Down Economy

Many articles, discussions, and presentations have been made on how the recent economic downturn affects the companies’ EA and SOA efforts. Some, like Joe McKendrick of ZDNet, believe that slow economy can spell boon for SOA but subprime SOA will suffer. Dave Linthicum published the results of his survey indicating the same. Beth Gold-Bernstein of ebizQ suggests that we bet the farm on Complex Event Processing. Ronald Schmelzer of ZapThink advocates that companies should continue to invest in SOA in a down economy. I would go a step further. EA and SOA investment is critical to the companies’ success – it will enable them to stay competitive, achieve significant efficiencies, and potentially even gain market share.

Pretty bold statement, some would say. I don’t think so. Let’s consider the facts.

When the times are tough, the first thing most companies do is slash budgets. IT budget gets reduced just like everyone else’s. The focus shifts from the strategic initiatives to simply keeping the lights on and completing projects as quickly as possible. Enterprise Architecture efforts are usually the first ones to be eliminated or significantly reduced. Point solutions become the norm resulting in duplication of software, hardware, and overall efforts. Smokestack applications rise up from the ashes of the Enterprise Architecture. Everyone becomes more concerned about keeping their jobs rather than doing the right thing for the company. IT managers shift to the aggressive empire building mode in order to protect their jobs and eliminate their own risks. (The old mentality of “I own more than you, therefore I am more important than you” is still alive and well, unfortunately. IT managers also think that if they can “own” and control every piece of their application, it will reduce their risk and allow them to deliver results faster.) Governance becomes unenforceable and largely forgotten.

Through this chaos, interesting trends emerge. While the initial IT budget is reduced through a series of staff reductions and some technology rationalization efforts, the costs begin to creep back up in subsequent years. When the economy finally turns around and the pressure to keep the budget low eases, the IT budget suddenly becomes larger than what it was prior to the cuts. Why? The explanation is simple. The empire building and unfettered decision making by IT management finally bears fruit. There are more software, licenses, hardware, and code in the data center, all of which requires more people to support. There is very little reuse and sharing because each group has built silo applications residing on their own unique platforms. Costs increase, efficiencies decrease, and it takes longer to deliver new capabilities especially if they require several applications to integrate with each other.

Enterprise Architecture and SOA can help reverse these trends and, in fact, keep the IT budgets low. Most companies have a number of redundant systems, applications, and capabilities that have grown through the type of uncontrolled behavior described above. EA, through an effective discovery and governance mechanisms, can eliminate these redundancies while maintaining the same capacity and level of operational responsiveness. Additionally, EA groups can influence or implement new architecture approaches to help consolidate resources and gain efficiencies. Examples of this could be virtualization, green technologies, cloud computing, etc. SOA, as a subset of EA, provides much the same benefits. Encapsulating key business functions as reusable services will help achieve more consistency, save money, and enable faster project delivery. An effective EA program can protect companies’ IT budgets from ballooning by establishing and enforcing standards, promoting reuse opportunities, and ensuring transparency across all IT systems.

The bottom line is that companies can not afford not to invest in EA and SOA. These programs will make organizations more efficient through the economic downturn and help achieve the necessary savings. On the long run, EA and SOA will keep the costs down while increasing business agility. Effective EA and SOA programs are a competitive advantage, not an overhead. They will easily pay for themselves and, what’s more important, enable organizations to avoid uncontrolled spending in the future. Enterprise Architecture and SOA is a must, not an option!

SOA Ecosystem

In the previous post, I’ve discussed the role of the ESB in the SOA ecosystem. However, I failed to adequately describe what an SOA ecosystem was and what were all the inter-relationships that must exist in order to make it truly effective.


If you refer to the diagram above, you will notice several major components that make up the SOA Ecosystem.

1. ESB
2. Registry/Repository (RegRep)
3. Security
4. Service Management
5. Shared Service Environments
6. Service Consumers
   

The SOA Ecosystem also encompasses all the related elements such as the application and service developers and testers as well as all the tools being used to accomplish these activities.

To truly comprehend how the SOA ecosystem operates, a clear understanding must be developed of what each component does and what its role is. Let’s start from the service consumer side.

• Service Consumers
  
  • Application Developers build applications that consume services. They use IDEs and other development tools to construct service requests and parse responses. Developers interact with the Registry/Repository to find the right services, obtain service metadata, and understand usage patterns.
  • Application Testers perform quality assurance tasks on the final product.
  • Application Servers that execute the application code interact directly with the SOA platform hosting the services.
• SOA Infrastructure
• Service Management Platform acts as an entry point into the SOA infrastructure. It retrieves policy information about the service being executed and applies it appropriately to the request. The policy is used to understand service security and authority, associated SLAs, constraints, contracts, etc. The Service Management Platform is often utilized to keep track of the service consumption and run-time metrics, which are then fed into the Registry/Repository.
• The role of the Enterprise Service Bus has already been discussed.
• Registry/Repository acts as a central repository for services and their metadata. Its uses and integrations are discussed at each related point.
• Security / Authentication Platform is a part of the larger IT infrastructure and is typically represented by either LDAP or Active Directory technology.
• Shared Service Environments are used to host reusable services. While different organizations choose to approach service hosting differently, if a common service hosting platform can be established, many issues related to service scalability, performance, reuse, security, implementation, standardization, etc. can be easily resolved. A centrally managed platform can be easily upgraded to accommodate additional – foreseen or unforeseen – volume. Standard capabilities can be provided to perform security, authentication, logging, monitoring, instrumentation, deployment, and many other tasks.
• Service Creation
• Service Architects and Developers create reusable services using the appropriate design and development tools. They also interact with the Registry/Repository to discover existing services and register new services and related metadata. The created services should ideally be deployed into a Shared Service Environment.
• Service Testers perform quality assurance tasks on the new or modified services. They use special SOA testing tools to create test cases and automate their execution. These tools interface with the Registry/Repository to retrieve metadata about the services and update related information once testing is complete.
  

Many vendors have slightly different view of how their products integrate and interact with the SOA ecosystem, what components exist, and where they are located. One can also include other elements into the SOA ecosystem such as the EA Repository, CMDB, IT Governance Tools, Monitoring Tools, etc. However, the general dynamics remain the same. The key point is that the SOA infrastructure interacts with the rest of the IT platforms and people in a certain way. In order for SOA to be truly successful, these interactions must become natural, automated, and symbiotic.

To ESB or Not to ESB?

That is the question. Many SOA thought leaders have addressed this topic. Most recently, David Linthicum wondered if ESBs were evil. He also talked about ESBs hurting SOA in his blog. Eric Roch has chimed in on the debate by providing some general guidelines for how to use the ESBs. Joe McKendrick has summarized the recent debate in his blog.

There seems to be a lot of pent up emotions in the industry when it comes to the ESBs. A lot of people tend to view ESBs as over-engineered, complicated, and unnecessary. Maybe, it is a backlash from the vendor hype or consistent experiences with a failed ESB implementation. Maybe, it is a reaction to the industry’s push towards choosing the tools first and fitting the solution into them later rather than vice versa. Maybe, it is a response to the architects calling the ESB implementation Enterprise SOA. I don’t know. What I do know is that ESBs have its place and when properly used are very useful.

SOA in not just about exposing services via a ubiquitous protocol and letting people use them. A successful SOA must have the following elements in place:

• Governance and Processes
• SOA Governance
• SOA Methodology
• SOA Reference Architecture (and possible Reference Implementations)
• SOA Maturity Model
• Service testing and versioning approaches
• SOA design patterns
• Technology
  
  • ESB
  • Service Management platform
  • SOA Governance platform
  • Registry / Repository (often is part of the SOA Governance platform)
  • SOA testing tools

The diagram below depicts the preferred SOA ecosystem and relationships between all of its different components and actors.



Note that the ESB plays a central role in the SOA ecosystem. It needs to be tightly integrated with the Registry/Repository tool that will store policy information and service metadata, service management platform that will ensure compliance to the predefined policies, and platforms exposing the physical service endpoints. ESBs are very useful when utilized to perform the following tasks:

• SLA and policy management
• Security reconciliation
• Protocol reconciliation
• Message transformation
• Orchestration (possibly, in conjunction with a BPM tool)
• Integration
• Logging and instrumentation
• Metrics collection

ESBs can provide all these capabilities in a central location and in a consistent fashion, so that every service does not have to implement them individually. Every service has to perform each of these tasks in some way, shape, or form. Without a central tool, implementations, tools, and approaches will vary. At the end of the day, you will end up with a hodge-podge of different things, which will be hard and costly to maintain.

When services are created, it is impossible to know who and how will consume them. In fact, it should be irrelevant. Services should not worry about all of the potential consumers, protocols, and contracts. It is the job of the ESB to reconcile all of them. Services should not have to include all of this complexity in their designs and implementations. They should only make sure that the business logic is properly implemented and a standard interface is provided. The ESB will take care of the rest.

Obviously, without proper planning and architectural oversight, ESBs can fail. Using an ESB to support only a handful of services is an overkill. Blindly choosing a product without performing adequate analysis always leads to problems. However, putting ESBs in the right place in the SOA ecosystem and utilizing them for the right purposes will only simplify the development, increase efficiency, clearly distribute the responsibilities between architectural components, and improve standardization. ESBs are not evil when used correctly.

Project-Oriented SOA

Read my article on the Project-Oriented SOA in the SOA Magazine.

http://www.soamag.com/I21/0808-2.asp

SOA Testing

Many articles, books, and conferences dealing with the SOA tend to ignore one of the most important topics in software development – testing. Often, testing is just an afterthought in many software development efforts. A lot has been said and written about this problem. However, it is important to note that testing in an SOA program plays a much more important and prominent role than in any other software development effort. Without a proper testing foundation, the whole SOA initiative will either fail or become too unwieldy or expensive to maintain.

One of the cornerstones of SOA is service reuse. Success of the SOA program is often measured through the amount of services created and reused. The biggest problem with testing in an SOA environment manifests itself when a service has several consumers and changes are made to it. How do you validate that this change does not impact service consumers? How do you determine the best way to deal with this change? Do you ask all of the service consumers to perform their own regression testing to make sure internal service changes do not impact them? Obviously, this is not an effective solution. With more and more services getting more and more reuse, you need a solution that minimizes the amount of manual testing you need to do but, at the same time, provides a clear understanding of how the service changes impact its consumers.

The services are composed of three primary elements – interface, contract, and implementation. Interface represents the protocol and communication mechanism between service and its consumers. Contract defines all of the interaction details such as message formats, SLAs, policies, etc. Service implementation is self-explanatory. A service can expose multiple interfaces and may potentially support multiple contracts. The key to understanding the impact on service consumers is to verify whether or not changes to any of the service elements invalidate how it behaves today. Changes that have no impact are called non-breaking; changes that modify the behavior are called breaking.

Each shared service needs to have an automated test created as part of its normal implementation. It will address two issues – provide an initial test bed for the service and automate all future testing needs. The test should inspect what changes are made to each service element. When service is modified in any way, the automated test suite should be executed to understand the impact of the changes. If all tests pass, the changes should be considered non-breaking and consumers should be unaffected. If any of the tests fail, this would indicate a breaking change and a new version of the service would need to be created. Alternatively, the impacted consumers can change but, ideally, breaking changes should trigger a new service version.

The biggest problem with SOA many companies face is lack of a consistent, comprehensive testing approach. Without automated regression testing for shared services, organizations are exposed to risk of high manual testing costs every time a service is changed or new consumer is added. Additionally, it can drive service versioning and serve as a formal validation mechanism that service consumers can trust. Automation can save millions of dollars in manual labor and ensure stability of the whole SOA platform.

Context Delivery Architecture

At the last Gartner Application Architecture, Development, and Integration (AADI) Summit held in Orlando, FL at the beginning of June, William Clark introduced the concept of Context Delivery Architecture (CoDA). It is an architecture that is aware on the end user’s context such as location, preferences, identity, etc. and delivers the information that is most suited for it. Another way to describe it is WYNIWYG (what you need is what you get) services. The basic idea is that users’ specific context will drive what information they receive, how the applications interact with them, and where the processes take them.

Despite Gartner labeling CoDA as an emerging trend, I don’t believe it is a new concept. Context and location aware applications have been in existence for a while. Think back to the Internet bubble days when all kinds of schemes were designed to deliver coupons, advertisements, and other “useful” information to your mobile devices when you got close to certain location. RFID and its applications became the staple of context aware applications. Even Gartner based its research on these trends. It is true, however, that CoDA has not yet become mainstream and is moving up the Gartner hype cycle curve.

CoDA is still very immature. The vision is that CoDA applications will ubiquitously run on a variety of devices, technologies, and platforms. For this to become a reality, technology needs to be created that would allow the same services to be delivered to a variety of platforms that possess the same context aware capabilities. Users should benefit from being mobile, not be hampered by it. For example, salespeople that left the office for the client visit should be able to obtain specific customer information, find out sales status, and view the whole relationship picture immediately on their preferred device. The same capabilities should exist on all mobile platforms, which will truly make context aware applications possible. At the same time, mobile devices should evolve to ubiquitously interact with the network. Whether a WiFi, cellular, or any other kind of network is available should not prevent the application and the device from performing their functions.

Even though CoDA was billed by Gartner as the next step in the evolution of SOA, I don’t think it fits into the same paradigm. SOA’s primary goal is to create composite applications through the leverage of existing services. EDA, or as Gartner likes to call it, Advanced SOA, pursues the same objective, except that instead of services, the same events are sought to be consumed. By contrast, CoDA aims to enhance user’s experience through the knowledge of his/her context and tailor the application behavior to it. While it builds on the concept of reusable services that would deliver the right information at the right time, the whole concept has nothing else in common with SOA. In my opinion, CoDA is a move towards more intelligent applications but it is definitely not the next evolution of SOA.

CoDA still has a long way to go. It is an exciting concept that has science fiction written all over it. However, the technology, devices, networks, and people are nearing the point when context aware applications will become commonplace. The exciting thing is that I don’t think we have much longer to wait.

Starting on Your SOA Journey

Many industry leaders believe that SOA should be started small and evolve over time. The argument is that this approach gives companies an opportunity to implement SOA practices on a small scale, test them out in a controlled environment, and understand how everything would work within the organizational boundaries. This is not a bad idea. However, I believe that the most effective way to introduce SOA is to build out the whole infrastructure, introduce the necessary technology, and establish all the patterns, best practices, reference architectures, and governance mechanisms before creating a single service.

The reasoning for this is simple. SOA on a small scale is not SOA. It is just a bunch of services. SOA’s goal is to create and leverage services across the organization. A single project or a couple of services cannot achieve this. Furthermore, effective governance, best practices, and lifecycle processes cannot be established on a small scale. They need to be designed and implemented with the large scale in mind. Testing them on a single project is not only impractical – it doesn’t provide any knowledge of how SOA will truly work within the organization.

Any successful SOA implementation will eventually have all of its elements in place – infrastructure, technology, governance, practices, processes, and people. Consider the impact of growing all this organically. You will end up with a hodge-podge of services implemented on different platforms using different approaches and design patterns. The technology set will be inconsistent. Governance mechanisms that typically tend to be established late in the game will most likely allow inadequately designed and implemented services to go into production. All this would have to be remediated at some point of time. Imagine the effort required to clean up years of organic growth! Most companies simply move on and leave the mess behind.

Now imagine what will happen if all of the SOA elements are in place from the very beginning. No rework, re-platforming, or cleanup will be required. All of the services will reside on the right platform that can be scaled for future demands, all of the best practices will be followed, and the governance mechanisms will be able to catch most, if not all the subpar services. The company will be able to reap SOA benefits right away without having to do the costly cleanup or conversion.

Of course, waiting to complete all the preliminary work can take years. No company, regardless of how strong its commitment to SOA is, can wait that long to start seeing the benefits of something that will require a lot of upfront investment. Thus, the most pragmatic approach is to introduce as many SOA elements as possible that will provide the most complete and consistent SOA foundation for the future. This should be achieved within a reasonable timeframe, so that services can start to be built and benefits can be quickly shown. All the remaining strategic tasks should continue to be addressed in parallel with the ongoing tactical service implementations.

The prescription above will not cure all of your SOA ills but will introduce a dose of prevention for the future. Building services following a consistent set of standards, using a consistent set of tools, and deploying on a consistent platform from the very beginning will ensure the success of your whole SOA program, not just a few projects or services.

SOA and EDA - One and the Same

Event-Driven Architecture (EDA) has received a lot of coverage lately. Gartner’s analysts spent a lot of time last year talking about it and promoting their ideas on how it relates to the Enterprise Architecture. A lot of companies, lead primarily by the financial institutions, have taken the plunge into the EDA. Alerts offered by virtually every bank are a good example of this. However, I do not feel that the relationship between EDA and SOA has been fully explored yet.

EDA is based on the concepts of events, publishers, and subscribers. At the most basic level, the idea behind EDA is that publishers publish events and subscribers consume them. Of course, some logic and rules must be applied to properly route the events. Through this mechanism, systems become connected in a loosely coupled fashion. This makes the integrations a lot easier and eliminates the need for each publisher and subscriber to know the details of how to communicate with each other.

Sounds familiar? Absolutely! Change the terms events, publishers, and subscribers to services, providers, and consumers respectively and the paragraph above reads like an explanation of SOA. Why is this, you would ask? Because EDA is nothing more than an asynchronous version of SOA. The major difference between the two is that services are typically implemented as real time calls while events are published and consumed asynchronously. All the other concepts are virtually the same.

While the architectural approaches and design patterns for EDA are slightly different from SOA, the fundamental concepts are still the same. A central event handling infrastructure that knows how to receive, route, and transform the messages is required. It should be viewed as practically the same thing as the Enterprise Service Bus (ESB). In fact, generically, I would call it the Enterprise Eventing Bus (EEB). As events are published, they need to be translated into a common representation, so that a consistent set of rules and operations can be applied to them. A canonical model is the best solution to achieve this goal. Additionally, the same façade pattern should be used as described in the SOA Façade Pattern post to abstract the publishers from knowing and being tied directly to the Enterprise Canonical Model. Note that the logical EDA architecture presented below is very similar to the one introduced in the SOA Façade Pattern.

Events, just like services, should be registered and be discoverable via a central Registry mechanism. Subscribers looking to consume specific events should be able to discover them at design time and receive them from EEB at the run-time. Design of the events, their publication and consumption should also follow the same standards and patterns as service design. All of the related documentation should be stored in the same centralized repository. Governance mechanisms applied to events should also be very similar to those applied to services. EDA does not require establishing a completely new governance model but can effectively leverage existing SOA governance practices.

The bottom line is that EDA and SOA are virtually the same architectural approaches. If you think about EDA as an asynchronous version of SOA, everything else will fall in place.

SOA for the REST of Us

There has been a lot of discussions comparing REST with SOAP and presenting various points of view on how these technologies affect SOA. The opinions expressed are widely varied. Some believe that REST is the best thing since sliced bread because it reduces load on the network and eliminates the unnecessary complexity of the WS-* standards. Others argue that REST cannot yet be effectively used with SOA due to the protocol’s relative immaturity. More and more, however, we are hearing voices of moderation that consider both approaches complementary.

I believe there is place for both REST and SOAP in an SOA program. You cannot necessarily prohibit the use of one technology over the other with one notable exception – you cannot yet standardize solely on REST. SOAP should still be considered the preferred protocol with REST being utilized in very specific situations. There is a number of reasons why.

1. Enterprise applications require enterprise capabilities
   REST was designed for simple Web-based interactions, not for complex enterprise applications. A plethora of WS-* standards exist specifically to address the complexity of enterprise integration and interaction needs. Capabilities such as transactions, security, policy, guaranteed delivery, and many others are a must in any enterprise caliber system. REST does not yet support this level of standards and, most likely, never will due to its focus on simplicity and performance.


2. Security
   REST does not support any specific security standards. In fact, it relies on the infrastructure and middleware to secure end-to-end communications. If service consumers have more robust and complex security requirements than can be met with the underlying infrastructure alone, REST becomes insufficient.


3. Strong contracts
   Strong adherence to service contracts is the cornerstone of any SOA implementation. It ensures that services expose well-defined contracts and provide adequate information on how to access them. SOAP-based web services have built-in capability to validate their contracts. REST does not inherently support this type of verification. In fact, all the interactions between the consumers and RESTful services contain nothing more than a command and a list of parameters. It becomes the responsibility of the service to ensure the validity of the contract.

As a general rule, REST should be used when performance and simplicity are paramount, no special security requirements exist, and no complex interactions between the consumer and the service are necessary. The best uses for RESTful services should be considered simple extracts of small data sets, inquiries against open public data sources, calls to external vendors supporting the protocol, etc.

A number of SOA and middleware vendors are feverishly working on creating solutions that support both SOAP-based and RESTful services. Very soon, REST and SOAP will simply become some of the many communication protocol choices existing in the rich SOA toolbox. Most of the differences will be eliminated by a combination of server-side technologies and client-side frameworks. However, until this happens, strict standards should be established guiding the use and adoption of RESTful services.

SOA and OO

While SOA and OO are based on some very similar concepts, the approaches they utilize to achieve them are quite different. The biggest difference lies in the distributed nature of services. OO technology assumes local, in-memory calls while SOA assumes a distributed network of services. This fact drives a number of differences between the two technologies.

One of differences is the cost of traversing the distributed network boundaries. It is nontrivial in terms of complexity and performance. Service-oriented designs acknowledge these costs by putting a premium on boundary crossings. Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message passing rather than implicit method invocation. Compared to distributed objects, the service-oriented model views cross-service method invocation as a private implementation technique, not as a primitive construct — the fact that a given interaction may be implemented as a method call is a private implementation detail that is not visible outside the service boundary.

Another difference is autonomy of the code. Object-oriented programs tend to be deployed and act as a unit. They are not autonomous but rather embedded into a managing container. Service-oriented development departs from object-orientation by assuming that atomic deployment of an application is the exception, not the rule. Services are deployed, managed, and run as autonomous units. They are, in fact, the containers, in which OO code lives.

The final difference is the architecture. Since OO almost always deals with in-memory calls, it places no premium on the number of method invocations and the amount of data passed. In fact, the best OO interface contains many methods that are created for a single purpose. Under SOA, network overhead needs to be considered. This fact puts a premium on the amount of calls made from the client to the service. Thus, the number of service calls should be limited while the amount of data passed should be maximized.

Keep in mind that OO and SOA are not competing but rather complementary approaches. Think about service as an outer shell of an OO application that enables it to become sharable across the network.

Creating and Managing a Canonical Model

As I discussed in my previous post (http://leoshuster.blogspot.com/2008/05/soa-canonical-modeling.html), a canonical model is a critical element in any successful SOA program. However, given the fact that it should describe the business completely and in a standard way, the resulting model will most likely be very large and complex. Thus, a natural question begs to be asked: how do you create and maintain a canonical model?

There are basically three ways to create a canonical model.

1. Buy it or adopt an existing industry standard model
   There is a number of organizations that either developed a set of standard models targeting a specific vertical (e.g. IBM - http://www-03.ibm.com/industries/financialservices/doc/content/bin/fss_ifw_gim_2006.pdf) or maintain industry standard definitions (like MISMO for Financial Services or ACORD for insurance). You can adopt one of these models to serve as the canonical representation of all the business entities.




Pros:



• Most of the work is already done
  
• Another organization maintains the model for you and introduces changes as necessary
  
• The model is standard and should help with external partner integration
  


Cons:



• The specifics of your organization may not be complete captured, which require custom additions to be made
  
• Some changes or customizations may be needed that would make it harder to upgrade in the future
  
• The elements are too generic or unnecessarily complex
  
• High learning curve for canonical model consumers
  






2. Create it from scratch
   A canonical model is created from scratch and built out completely before any work utilizing it can begin. This would require at least 3-6 months of effort meeting with various groups across the organization, collecting and sorting the information, and validating the result with the potential users.




Pros:




• Would provide the most complete and targeted model
  
• Users will have innate knowledge of the model since they helped build it
  


Cons:




• Requires all projects that need to use the canonical model to stop until it is completed
  
• Not highly realistic or pragmatic approach
  
• Requires modifications to be made and managed internally
  






3. Build it incrementally
   A canonical model is built incrementally over the span of multiple projects. Only those elements that are required by the project are added or modified.




Pros:




• Does not require a lot of upfront effort to get started
  
• Efficient and demand-driven – model only what is needed
  
• Low learning curve – users have more opportunity to learn it as the model evolves
  


Cons:




• High propensity for change – the model is frequently refactored as new projects leverage it
  
• Requires a centralized team to own or govern it
  
• Frequent changes would require a large amount of testing and updates to the existing consumers
  

The best way to manage the changes to the canonical model is to establish a centralized team to own the whole thing or to provide governance over it. It would be responsible for making / tracking the changes, notifying consumers, performing compatibility testing, versioning, training, and communications. A comprehensive list of all the canonical model consumers needs to be maintained in order to notify them of all the relevant changes and understand the overall impact of modifications. Without a centralized team, there can never be a canonical model because there will be no one to synchronize or drive all the disparate efforts towards a single goal.

Regardless of the chosen approach, changes to the canonical model are inevitable. Therefore, the façade pattern described in one of my earlier posts must be utilized when using canonical models in the SOA context.