Overview

BOF4WSS, displayed in Figure 3.1, was conceived to address the outstanding security issues identified in Chapter 2 and strengthen available security/trust solutions. The framework consists of nine stages which, in general, semanti- cally resemble those found in typical systems development methodologies. For- mally these stages are Requirements Elicitation, Negotiations, Agreements, Anal- ysis/Architectural, Agreements, Systems Design, Agreements (for Quality-of-

Services), Development and Testing, and Maintenance. Compared to typical

methodologies, the Negotiations and Agreements stages are novel. Their inclu- sion was found to be crucial in BOF4WSS noting the cross-enterprise nature of the development and imperative need to discuss, negotiate and agree on clear paths forward.

Agreements (for QoS) Requirements Elicitation

Negotiations Agreements Analysis/Architectural

Systems Design

Development & Testing Agreements

Maintenance

Figure 3.1: BOF4WSS Overview

The Waterfall Model (WM) methodology [103] in particular was the main influence for the framework’s design. This can be seen when comparing the frame- work’s phases to those of the WM, such as system feasibility study, requirement analysis and project planning, system design, detailed design, coding, testing and integration, installation and maintenance [103]. Depending on the article sourced, the stages of the WM may be named differently (for example, [177, 16, 193, 213]); [103] is referenced because of its detailed view of typical WM tasks/stages.

3. The BOF4WSS Approach 41

The WM was preferred to other methodologies such as prototyping [133], spiral [16] and object-oriented [81] approaches due to the transparent, well- organized, highly documented, and strongly disciplined process it can bring to a large inter-organizational development project [103, 18]. Some practitioners even view the structure possible with the WM as an ideal fit for the corporate (somewhat bureaucratic) world and a key reason why the WM is here to stay [27]. With appreciation of the flexibility and quick turnaround benefits of ag- ile and more lightweight methods, these were also considered at length. These techniques were not chosen for the framework’s foundation however, because lit- erature [193, 213] does not advise them in situations: (i) of large development projects, (ii) where development teams might be in different places and dealing with complicated interactions with other hardware and software, or (iii) in critical systems development. These are all likely situations where BOF4WSS might be used, as mentioned in previous (Section 2.3.3) and also, later sections.

Despite the benefits listed, it is accepted that the WM does have short- comings and criticisms. For example, researchers have identified that it lacks flexibility in the original model when traversing stages and freezes requirements too early [103, 16]. To compensate for these concerns, BOF4WSS allows for flexibility through bottom-up progression and feedback (shown on the right in Figure 3.1). Additionally, even though requirements are determined early in the framework, these are only high-level requirements (as opposed to the traditional WM that defines all requirements) which may change (subject to agreement) at subsequent stages closer to design.

Underlying both of the points above is the emphasis BOF4WSS places on the involvement of key stakeholders throughout the entire process to ensure gathering and circulation of necessary information, making of changes and so on. The prime novelty in BOF4WSS is found in its emphasis on providing a collaborative development methodology which focuses on WS security. This methodology would accommodate multiple autonomous businesses working to- gether. To address the outstanding issues from Section 2.3.3, BOF4WSS aims at:

considering the full nature of WS and its security implications within e-business; appreciating the real-time inter-organizational security issue now faced by inter- acting e-businesses; and finally promoting the use of a collaborative approach to provide enhanced levels of security and trust. These are its high-level design goals.

As will be seen below, the framework and its phases give detailed guidance on what should occur and how, and its relevance in attaining desired levels of

holistic security for these cross-enterprise interactions. To recap, cross-enterprise

interaction security refers to ensuring businesses are secured internally, but also

that the external interactions encompassing collaborating businesses are secure

to some level. External interactions with a company simply mean interactions that occur in transit (that is, while they are being passed between companies), and to some extent what occurs regarding the security of these interactions while being processed by business partners. This internal and external focus is revisited at various points in BOF4WSS’s presentation.

Returning to the point regarding detailed guidance given by the framework, this will involve defining the expected inputs to stages along with their required outputs/outcomes, but especially the recommended low-level goals, activities and steps within those stages that can help achieve the outcomes. Where suitable, this guidance aims to reference and reuse existing methods and practices—both from industry and academia—thus concentrating on the compilation of these into a coherent, well-defined process.

Another main design goal of the framework is to utilize Web services spec- ifications and tools wherever and whenever useful. This includes validated pro- posals from the research community as well. These choices were made to provide companies that adopt BOF4WSS with a practical methodology that pulls to- gether key WS specifications and tools from the plethora of technologies available. Furthermore this shows exactly where and how they can fit into the development of a WS solution. To date, the author is not aware of such a broad methodology as BOF4WSS, which aims to fit together a majority of the critical pieces of the WS

3. The BOF4WSS Approach 43

security puzzle in the context of cross-enterprise, highly structured, extensible (allowing approaches/tools to be plugged in), business-oriented framework.

To support the largely textual description of the framework’s activities next, a number of diagrams are included illustrating each stage and its respective workflow. Since security issues are a central concern to BOF4WSS, the discus- sion concentrates primarily on these aspects rather than an isolated discourse on functional and quality related aspects. Quality aspects or requirements in this re- gard refer to non-functional requirements excluding security, such as performance, scalability and so on. At some stages however, in the interest of completeness, this chapter does give some guidance on these areas. This is particularly when they relate to useful WS standards and technologies.

Lastly, BOF4WSS assumes that businesses have previously agreed (through feasibility studies, initial dialogue and so on) to use WS to support a generally de- fined business scenario. In other words, the broad scenario is known. BOF4WSS’s task therefore is to provide a methodology for its planning, development and im- plementation. Below, the framework’s stages are presented.