A well known development method is based on Service Oriented Architecture. One of its claimed benefits is the re-use of services already built. Re-use will lower the costs of development and maintenance and could minimise the time to market for new functionality. In order to efficiently decide which services can be re-used, one needs to know which services are already available. This is the first problem. Often, there are already much services built over many years. No one has the overview of the services currently available. When one does know a service that is applicable for re-use, another problem is that there is no insight into what effect a change of this service might have on other, related services. It might be that a small change in service A will result in a big disfunctioning of service B, C or even Z further down the chain of interactions.
SoaVis can help to provide an overview of all services which is easy to browse and navigate. For each service, it shows at least the basic functionality and the relations with other services and systems. Changes in the overview are immediately visible, whether there is a new service added or the relations of an existing service are changed.
Generally, a good solution starts with a Central Repository which stores all services and their designs (both internal workings as well as the external interface). Often this Central Repository is already in place but hard to use for analysis. It mostly consists of the base code and maybe (if lucky) some separate interface definitions.
SoaVis however, is a solution that will enable the dynamic visualisation of the services in the Central Repository. It provides an interface which is accessible for business managers, architects, developers and even testers and support operators. It comprises more than just a tool. It provides a means of solving the problem in a complete set of working process guidelines supported by a set of tools. Are you using a tool not mentioned on this site? No problem, call us and we will help adjust your tool set.
Every company using services or any other means of SOA could benefit from this approach. More specifically:
- The business managers could browse through the publicly available services to get insight into what is already available. With that knowlegde, they often think of new functionality that could be easily provided by just re-using existing services in a different way. For instance, look at a Customer Service Center where the representatives are using a set of services to determine the current portfolio of the customer. Using the same set of services, this same portfolio could easily be shown on the internet where the customer is logged into his private page.
- Solution Architects could analyse both public and private services to determine the most efficient way to solve a problem for the business.
- Service Designers can analyse the services to determine what the impact of a change might be for other services.
- By coupling other information to specific services, testers could generate overviews of the status of a service, whether it is accepted or there are still errors.
- Project Managers can use the relations of services to determine the dependencies between different projects touching the same services.
- Support Operators could get insight into the use of services when the performance information is coupled. Every service could provide a history of information like how often it has been called per day, week or even hour if desired.