For accessing Derby http://db.apache.org/derby/integrate/plugin_howto.html

Myeclipse can be used to browse across almost any of the databases. It can let you run DDL and DMLs for any databases. If you are familiar with eclipse, this is a nice and easy to use tool. Only downside is that you will need to get JDBC drivers for various databases that you want to connect to.

Oracle SQL Developer for accessing Oracle database.

Toad for accessing various database.

IBM’s DB2 Control Center for accessing DB2 database.

• The Problem faced by Enterprises today

Over last few decades, Information Technology has played an important role in enabling organizations to deliver its products and services. As we can see in Figure 1: History of Computing, over last several decades we have seen significant changes in the way software systems are developed and used.

Figure 1: History of Computing

In the early days of computing, we had so called FAT client application where in all the required components for executing an application would reside on one hardware system. These computing models fulfilled the early requirement of making the process automated and improve the productivity. However, as the time progressed it became too difficult and costly to maintain this kind of stand alone applications. As a result computing model moved towards a distributed environment also called as two tier client-server architecture. This model allowed applications to divide applications into two parts where in client can be running on a hardware system with less computing power and server can execute on systems that require higher computing power. This model provided significant reduction in the cost as well as greater flexibility, reliability and scalability for the end users. Evolution of Internet and software standards generated a new wave called n-tier architecture where in application processes are spread across different hardware systems. While the n-tier architecture possesses some strong advantages over the client-server architecture in terms of ease of deployment, platform support, performance, and scalability, none of the architecture solves one key software-engineering problem in the enterprise computing space: how to reuse functionality written for one application in another. As a result of this problem one of the major IT cost for an organization today is spent on integration of different systems. It is often heard from the business users that their IT systems are hindrance for their growth or due to the complexity of their systems it becomes difficult for the companies to react to the changing dynamic market. Some of the reasons given for this behavior are strong coupling between business processes and IT systems. Although these solutions allow users to integrate desperate systems available in the organizations, it requires lots of effort and labor work force to make any changes into the existing applications. These problems lead to the necessity for a change; a change that would create loose coupling between different systems available, applications that are dependent on available standards that would allow organizations to plug and play with these modules, modules that are componentized and that enables the creation of business processes by orchestrating different modules. And this need for a change is forcing the emergence of a new computing model called as “Service Oriented Architecture” or SOA in short.

• What is SOA?

At its simplest SOA can be considered similar to set of Lego bricks which can be assembled together to build a model of almost anything imaginable such as cars, planes, buildings. In a similar way, SOA allows software programs to be componentized with a standard interface around it. This software component can then act as a “service”, which can later be used by any other applications as needed. Organizations can create library of these “services” which can then be mix and matched to create any composite applications to support any business processes or business needs. These loose coupling not only provides flexibility for any changes in the business processes but it also provides cost savings by reusability of these services by different processes. Unlike traditional approach of application building, in which chunks of reusable code were compiled to create new applications, services can live on widely distributed servers, ready to be tapped only when needed.

Figure 2: Example of a “Service”

• SOA Life Cycle

When moving towards SOA, one needs to decide where to start. One of the quick and dirty approaches that many organizations may take is to just start building webservices. However one need to understand that webservices is not an SOA. This approach may provide some benefits at the beginning, however over the long term benefits may not be as prolific as it would have been with a sound and thoughtful approach towards SOA. Some of the key steps when moving towards SOA are listed below. The key to a successful SOA adoption is careful planning around the architecture’s entire life cycle, from initial development of services through deployment, management and change. Although there is no single rule for moving towards SOA, stages described below would help organizations to move towards SOA and in the long run accomplish benefits of SOA.

Figure 3: The SOA Life Cycle

Strategy
To tap the full benefits of SOA, organizations should view the technology as more than simply a convenient way to make components interoperate with each other. SOA is also a foundation upon which to introduce more technically sophisticated approaches to changing business requirements. But because it involves the foundations that support the business—processes, applications, data, security—formulating a clear strategy is critical. Tactical SOA projects are not the only way to proceed. Multi-phased strategic projects may provide a bigger bang for raising the visibility of SOA within the organization at higher levels. CIOs must demand increased budget commitment to bring SOA’s promise to fruition. Organizations should start with holistic and strategic approach for SOA planning, which will include a roadmap, transition plans, and metrics for quantifying SOA’s value and results.

Enterprise Business Architecture

One of the starting points for going towards SOA is the creation of Integrated Enterprise Business Architecture (EBA). EBA provides a holistic view of the enterprise from the perspective of various stakeholders, customers, supplier and employees. A holistic view of the enterprise allows organizations to understand the cause and effect of actions taken by one business unit on to another one. Also creation of EBA through decomposition of business processes allows identifying common process that can be modularized while creating “services” for SOA.

Develop

During the development phase organizations need to understand and find smallest unit of processes that can be developed as “service”. Before developing any new service stakeholders need to make sure that no such service already exists in the organization. These services need not be webservices and it should be capable of fulfilling some business function. It should provide some kind of interface for other services to interact in the later stages of the SOA life cycle.

Integrate

Once the service is designed and developed, the next step is to integrate it with other systems such as databases, legacy systems, ERP or other applications. This integration process may require some type of data transformation or data mapping as well as dynamic routing capability to connect different services. Integration need not only focus on the technical aspects of the services. It should also involve business side as well. Along with the EBA created in earlier step, instrument applications and analyze the events they generate to business process impacts, create links between different applications that would allow to react in real time to the most relevant information by ensuring seamless flow of information.

Orchestrate

Once the organization has developed few services, it can combine or glue them together to create some meaningful and seamless business process flow. This process of combining or gluing the services together to create a business flow is called as orchestration. This is the stage where advantages of SOA can be most visible for tying business and IT together. Well defined SOA would allow business personnel to react quickly to dynamic changing market.

Secure

As a next step towards real world “services”, one need to make sure that these services are secured and they don’t expose sensitive data to the unauthorized users. In order to protect the “services”, it is necessary to identify process for authenticating and authorizing the users of the services and map services against the type of the users to avoid exposing of any sensitive data to unauthorized users.

Deploy

At this stage of the cycle, services are ready to use for business processes. However at this stage one needs to make sure that services has Service Level Agreements (SLAs) associated with it. Although process of identifying SLAs need to start early in the design and development phase, at this stage one needs to make sure that service providers are aware of what is expected out of the service in terms of response time, availability, load handling and scalability. These SLAs would help to configure and scale the runtime environment to meet the service levels required by business processes. Once this configuration is performed, it is ready for deployment in the robust, scalable and secured service environment.

Manage and Monitor

Once the services are deployed and used by different business processes, it is very important to manage them. This phase involves establishing and maintaining service availability and response times as well as managing the underlying service assets. Some type of “impact analysis” mechanism would assist at this stage. This tool can create a dependency graph between different services and assets. This graph can assist the management or other stake holders to find how different business processes are inter-related and what will be the impact of action taken on one process towards other processes. This stage would also involve monitoring of services and analyzing any catastrophic events as a result of failures. Monitoring of services would help operational staffs to ensure the quality of services and identify any bottlenecks in the process. Any issues observed at this stage should be communicated to the respective stakeholders of the service providers. Any feedback provided at this stage should be communicated to the stakeholders of the service providers which would assist moving towards SOA as a continuous improvement process.

Governance
As we can see in the SOA Life Cycle, governance is at the centre of all the stages of the life cycle. In order to achieve maximum benefits of SOA, governance issues should be considered since the beginning of the initiatives and it can not be considered as an after thought. SOA creates an inherently dynamic and heterogeneous environment. It introduces many independent and self-contained moving parts — components that are typically widely reused across the enterprise and are a vital part of mission critical business processes. Governance is no longer optional — it’s imperative. SOA has the potential to introduce risk and, without proper governance, can disrupt business processes and create significant inefficiencies. Some of the key considerations at different stages of cycle to enforce the governance are listed below.

1. Create an architecture steering group that is responsible for enforcing and verifying standards used by different services. This group needs to make sure that there are no exceptions in the design of the service until and unless it is required. Additionally any introduction of new service should be approved by this group.

2. Architecture group also needs to make sure that there are no duplicate efforts done within the organization. This would reduce the cost of maintenance for similar type of services and promote the reusability.

3. Standards and policies can be defined and better approach would be to automate validation of services created against these standards and policies. Services are not allowed to publish if they do not confirm to the standards.

4. In order to ensure that services are discoverable, services can be published and discovered using some standard mechanism. One of the approaches for this is to have directory of services that would allow providers of services to publish the information in the directory and users of services to search the directory for the dynamic existence of service providers.

5. Since creation and maintenance of services is an ongoing process, it is very important to have that relationship between different services and processes are visible. This can be achieved a tool that can show this type of relationship as well as assist stakeholders of services to perform impact analysis i.e. what would be the impact of making changes in one of the services or which other services or processes may be impacted by the change.

6. In most of the application developments, security is afterthought. Most of the time excuses are given that our processes are running inside the firewalls and we don’t need to worry about security. In many such instances it is very difficult and costly to implement security in different modules of the applications at a later stage. Additionally it may be possible that different application providers use different security standards. Since services provided through SOA are exposed to various clients, it is very important to consider security aspects early in the cycle. It can be responsibility of the architecture group or a security group to make sure that services provided by different providers adheres to the standard and efforts are not duplicated.

7. Last but not the least, as mentioned earlier, SLAs should be defined for different services so that no surprises are observed when services are put into the production. This can be governed by enforcing runtime policies that would trigger events and actions automatically at runtime when services fail to confirm to specific policies or SLAs.

• Benefits of SOA

SOA has quickly captured the imagination of the business world because SOA’s technical characteristics translate directly into real bottom-line benefits. Boston-based research firm Aberdeen Group Inc. predicts that a fully implemented SOA will reduce deployment cost by 25% or about $53 billion over fiver years, across the 2000 largest firms worldwide. Some of the key benefits of SOA are listed below.

Loosely coupled architecture
As different services are loosely coupled in a typical SOA environment, it increases organizational agility where in organization can easily and quickly assemble different services in response to the changing market requirements. This also provides greater flexibility in the way applications or IT can be used to support the business.

Reusability and Cost Reduction
As it is possible to reuse the services created for multiple business processes, over the long run organizations can achieve economies of scale and there by creating higher cost reduction in terms of maintenance, test and deployment of these services.

Business and IT integration
In the past any changes resulted as a merger or acquisition would create lots of overhead for the business and IT department for the integration of various systems. However SOA increases IT adaptability where in changes resulting from mergers, acquisitions can be easily integrated.

Componentized and Phased approach
Since services are independent of each other, SOA enables incremental development, deployment and maintenance and avoids the need to do costly and risky “big bang” software implementations. Additionally it is not required to do all at once i.e. organizations can create a phased approach where in some of the business processes can be created with services created through SOA, this helps organizations to decrease development effort as complexity reduces.

Acceleration in the development and deployment
Over the long term, when most of the basic services needed for any new application functionality already exist, development and deployment of new application functionality is accelerated as it is mainly required to orchestrate existing services versus traditional model of new application development.

Standard based
As SOA encourages usage of standards for service creation, this enables organizations to utilize software and hardware of their own choice. Additionally for organizations that decide to outsource their IT development, standard based approach helps in a multi-source strategy and reduces threat of vendor lock-in.

• Risks and Challenges

The journey towards an SOA will not be an easy one. There are many risks and challenges ahead. These risks and challenges are listed below.

1. Reworking IT framework to move towards an SOA takes time, money and a strong business driver. If it is done correctly it would eventually save cost and increase agility of the organization. To do it correctly, everyone in the organization, both on the IT and business side needs to change the way they look at the business. It can force business side people to put off short-term opportunity in favor of long term goals. It can also make IT people to think differently as SOA would require IT staff to think in terms of services and business process. The challenge in building an SOA is to keep people—including both IT and business-side staff—focused on the architecture goals.

2. As services are exposed to many users and standards are still evolving, security is one of the biggest challenges to move forward. However proper governance and considering security early in the process would assist to overcome the challenges that may be faced in this context.

3. As more and more services are introduced complexity of the configuration also increases. It is very important to have architecture that describes relationship between these services and more importantly it is important to communicate to those users of a service if someone decides to change the interface of a particular service.

4. Finally, there is the cost issue. Building an SOA is not cheap; reengineering existing systems architecture is going to cost some serious money. It also requires significant human capital, including business analysts to lay out the business processes, systems architects to turn processes into specifications, software engineers to develop the new code and project managers to track it all.

5. It also could be a political problem, as certain groups in the organization may fund the service initially, but later other groups also start using the service and potentially causing prioritization issues and hurt feelings. The biggest question that may arise at that time is how to consider budgeting of the initial service development and which group is responsible for funding the services.

• SOA Best Practices

Although there are risks and challenges present during the journey towards SOA, these risks and challenges can be minimized by utilizing some of the best practices experienced by many of the organizations that have already jumped into SOA. Along with the governance model described earlier, some of the best practices for the successful adoption and implementation of SOA are listed below.

1. Get buy-in for broad SOA adoption from senior business and technology executives and line-of-business managers to help ensure success. Involve business users and different stakeholder from the beginning till the end of SOA implementation.

2. Create governance group of architecture, business people and other stakeholders to create and enforce standards for the SOA environment within the organization.

3. Instead of going with a “big bang” approach, deploy services in pieces with a long term plan. Plan to adopt SOA in a phased approach, starting with a single, low-risk application or a pilot program before broadening to other applications, across business divisions and eventually to an enterprise SOA infrastructure. It is very important to consider impact of various services on each other when these service move from version 1.0 to version 2.0. Careful planning and architectural blueprints of an organization can assist in this regard.

4. As explained in the earlier sections, take governance seriously from the beginning of the SOA approach.

5. If expertise does not exist within the organization, consider hiring new talent pool or getting outside consultants that has expertise not only in technology but also in business processes.

6. Business team and IT team must work hand in hand. Successful SOA can not be realized without the team support.

7. Fully embrace the use of open standards.

8. Communicate regularly on SOA developments and successes to keep people in the organization—as well as key business partners—aware of progress.

9. Create “lessons learned” from one projects and utilize it for the implementation of successive projects. Make sure that mistakes are not repeated and success measures are transferred from one project to the other projects.

10. Track the business benefits achieved in terms of revenue growth, reduction in cost, efficiency improvement and speed to market and communicate it to the C-level executives of the organization.

• SOA’s Key Technology Component

Although service-oriented architecture (SOA) is not about technology, technologies can help organizations to deploy an SOA. Standards and products are still emerging and not mature enough. Following technologies can help to ease the SOA effort:

Ø Enterprise service bus (ESB): A variation of an application server or EAI platform, an ESB orchestrates the communication among services, as well as with the user, legacy systems and any data sources. It also helps for data transformation and dynamic content based routing.

Ø Service registry or repository: This is like a database system that tracks the various service components available for reuse and publishes available services to business analysts and external partners so they know what’s available. Additionally it can also help to identify relationship between different assets, which can be used for impact analysis purpose during the change management.

Ø User interface management: As more and more organization move towards SOA approach, as per IDC research, the biggest development will be the whole user interface space. As more services exist in everything from Web portals to office tools, everything will be a producer or consumer of a service, and managing the user interface across everything will require a service-oriented approach as well. The emergence of asynchronous Java and XML (Ajax) “is a start but it’s not enough” for SOA’s broad reach.

Ø BPM and BAM are the two new waves that have been picking up from last two years. Something more about it later.

• Conclusion

SOA is an architecture and not technology, CIOs should not promise to deploy an SOA. Instead, they should promise to deliver business cirtical services using the SOA model. A complete SOA effort can take many years to deploy. Fortunately, SOA’s approach of breaking applications into discrete services means an SOA effort can be incremental, gradually replacing traditional applications. SOA empowers business people to develop their own services, but it still requires CIO leadership to manage that process. It both enables and demand alignment. SOA puts technology into business terms so business people can develop, reuse and change services themselves. It enables quicker rollouts at lower cost, providing faster time to market for new products and services and thus creates competitive advantage. Finally, journey towards the full implementation of SOA enabled enterprise is not an easy one and it would require commitment from the management, strong leadership, and talented pool of people with business and IT skills and effective governance model.

• ReferencesØ A guide to SOA success http://ww.softwareag.com/
  Ø http://en.wikipedia.org/wiki
  Ø Service Oriented Architecture (SOA) http://www.ibm.com/soa
  Ø CIO Magazine http://www.cio.com/soa
  Ø Strategies for SOA success http://www.oracle.com/
  Ø WSJ: Service Oriented Architecture http://www.sys-con.com/
  Ø Benefits of SOA http://www.webmethods.com/
  Ø SOA’s Technology Underpinnings http://www.cio.com/archive/050106/et_main_sidebar.html
  Ø SOA’s True Challenge It Ain’t Technology http://www.cio.com/archive/050106/et_main.html
  Ø A New Blueprint for IT http://www.cio.com/archive/081505/soa.html