Datasheet
P1: OTA/XYZ P2: ABC
c01 JWBT191/Bell November 1, 2009 14:39 Printer Name: Yet to Come
Driving Principles of Service-Oriented Discovery and Analysis 13
For example, misunderstanding of the problem domain at the project inception phase can
trigger an alternate solution that is offered by the analysis proposition. Discrepancies between busi-
ness requirements and architecture blueprints during the design and architecture project phase can
also result in an alternative solution. Finally, inconsistencies between the constructed services and
the architecture model may occur during the construction phase. This may result in disagreements
about the original development direction and approach that may call for an alternative solution
proposition.
PROPOSING A NEW SOLUTION. Occasionally an analysis proposition offers a new solution that
has never been proposed before. This occurs not because of misinterpretations of business require-
ments or noncompliance with design and architecture blueprints. An analysis proposition can be
crafted because an organizational concern has not been tackled, requirements were not provided,
design and architecture deliverables did not address a problem, or the development team has never
been commissioned to construct the required tangible services. The responsibility of a practitioner
is then to find these gaps in each of the project phases and conduct analysis and discovery sessions
to tackle unaddressed issues and concerns.
DRIVING PRINCIPLES OF SERVICE-ORIENTED DISCOVERY AND ANALYSIS
The service-oriented discovery and analysis process is a repeatable discipline that offers best prac-
tices and patterns to enable practitioners identifying and inspecting a service’s internal and external
design and architecture. From a service-oriented analysis perspective, this venture calls for a con-
tinuous investigation and assessment of service feasibility and contribution to a business or a tech-
nological problem. This endeavor also takes place during all service life cycle stages, during which
the subject for inspection differs in each step of a service’s evolution. As we learned in the Service-
Oriented Analysis Endeavor section, different artifacts are examined in each analysis iteration. The
same applies to the service discovery process and its related iterations, when service identification
opportunities vary in each service life cycle stage, as discussed in the Service-Oriented Discovery
Endeavor section.
This brings us to the chief principles that should be pursued to guarantee a successful dis-
covery and analysis effort, simplify its processes, and maximize its efficiency. The sections that fol-
low introduce these tenets and elaborate on their contribution to the service discovery and analysis
venture.
SERVICE-ORIENTED DISCOVERY AND ANALYSIS TRANSPARENCY MODEL. Transparency is one
of most intrinsic tenets of the software development life cycle initiative, and in particular it should
apply to the service-oriented discovery and analysis discipline. Transparency is about the justifica-
tion that practitioners must provide when making important decisions about service design, archi-
tecture, construction, deployment, or operations. In other words, every significant activity during
any of the service life cycle stages should be rationalized by architects, developers, modelers, ana-
lysts, and managers. They must not only clarify the reasons that led to certain business or technical
resolutions, but also indicate the cost, effort, and time of a solution implementation. Therefore, the
service-oriented discovery and analysis discipline calls for the establishment of the service-oriented
analysis transparency model that advocates architectural, technological, business, and operational
traceability during the service life span. The term “traceability” pertains to the process of tracking
the evolution of a service ecosystem and its business and technological drivers. Exhibit 1.6 illus-
trates these transparency components:
1. Architectural traceability. Architectural traceability is related to decisions that must be
reported and justified in terms of design practicality, cost effectiveness, and return on in-
vestment. These must be evaluated against organizational best practices, such as software
efficiency, reusability, agility, performance, elasticity, loose coupling, and interoperability.