 |
|
|
 |
||
 |
||
 |
||
 |
||
 |
||
 |
 |
|
 |
||
 |
||
 |
||
 |
||
 |
||
|
||
 |
Your independent resource on business integration and network computing through middleware and message brokering
Implementing applications in an SOA: consideration of best practices
Peter Bye
Unisys Systems & Technology
Management introduction
As has been stated many times by many people, including Mr. Bye, the IT industry has a poor record in developing new applications. If success is defined as meeting all the original functional and non-functional requirements within time and budget targets, the majority of IT projects fail on some or all of these criteria. Unsurprisingly, much effort has been expended in trying to find better ways of designing and implementing systems.
A Service Orientated Architecture (SOA) is the latest of the many attempts to improve the situation. The ideas behind SOA are intended to improve structures and encourage the re-use of existing applications in a new environment. As there are an increasing number of IT projects implemented using these ideas, it is worth asking what factors are likely to improve their chances of success. The factors take the form of 'dos' and 'don'ts': it is equally important to know what to avoid as what to do. In other words, as Mr Bye describes, these constitute best, or at least good, practice.
Mr Bye has looked at a number of the success factors individually in the past, for example the role of testing and the importance of considering non-functional requirements. His analysis here is a consolidation of these thoughts and other ideas. He begins by (briefly) explaining what he means by services and SOA, goes on to describe an example project and then examines the factors contributing to success or leading to failure. The example used is an amalgam of more than one real project with which he has been associated. It is not, therefore, a specific case but is realistic.
Figure 1.1: IT environment in The Organization before the SOA project
Figure 1.2: The Organization's target environment
Figure 1.3: Project life-cycle model
Figure 1.4: Defining the architecture
Management conclusion
In this analysis Mr. Bye has brought together a number of factors that can affect the success or otherwise of projects leading to composite environments such as that described in his example. While that example itself does not reflect a specific single organization, it is a composite based on several different projects on which Mr. Bye has worked. From this he is able to describe several of the factors that most often deliver success, such as best practice, or - at least - good practice. Many of the factors sound obvious but are all too frequently ignored for one reason or another.
In his view, the most critical time lies in the early stages of a project, in the particular project definition and the architectural design. Composite systems require a great deal of discussion, including proof-of-concept projects, to establish compatibility between functional and non-functional requirements, and the technology selected for implementation. There is likely to be much iteration around and within these stages. If this is not done, problems will be encountered later when they are far harder and more expensive to correct.
Procurement processes can adversely affect what is necessary by getting in the way of discussions and imposing a barrier between definition and implementation. There is a strong case for moving the procurement step to after the architectural definition.
There are, of course, other factors likely to affect a project, some of which Mr. Bye discusses above. These include staffing, test and diagnostic tools and procedures plus the management of transition to operations and the data centers in which the systems reside. Failure to manage any of these effectively can also affect the outcome of a project.
In summary, the most critical time for projects to go wrong is early on. Effort spent there will be repaid with interest later - which is what will enable SOA to make its contribution to an organization's success.