Service-oriented modeling and architecture (SOMA) has been used to conduct projects of varying scope in multiple industries worldwide for the past five years. We report on the usage and structure of the method used to effectively analyze, design, implement, and deploy service-oriented architecture (SOA) projects as part of a fractal model of software development. We also assert that the construct of a service and service modeling, although introduced by SOA, is a software engineering best practice for which an SOA method aids both SOA usage and adoption. In this paper we present the latest updates to this method and share some of the lessons learned. The SOMA method incorporates the key aspects of overall SOA solution design and delivery and is integrated with existing software development methods through a set of placeholders for key activity areas, forming what we call solution templates. We also present a fractal model of software development that can enable the SOMA method to evolve in an approach that goes beyond the iterative and incremental and instead leverages method components and patterns in a recursive, self-similar manner opportunistically at points of variability in the life cycle.

No abstract

No abstract

Industry experience indicates design engineers often have difficulty determining the initial set of key abstractions that constitute the key elements of a domain in a repeatable and nonarbitrary fashion. Key abstractions are a central, although often poorly explained and elaborated part of current analysis and design methods such as Unified Process and their identification can be a challenging task [8]. Instructions for how to perform this step are usually quite general and much is left to intuition. Often it is ignored entirely with the comment that the system architects will identify the initial key abstractions. Poorly chosen key abstractions lead to poor designs and require significant changes as the system is developed. A basic principle of software engineering is that it is always more efficient to do things correctly at the start rather than having to repair them after further development has occurred [4].Perhaps the most common technique for object identification (or object discovery) expounded in most methodology texts is to underline the nouns. Also, use-case analysis and responsibility-driven design (for example, using CRC cards) tend to be used in eliciting key abstractions in an intuitive way. These techniques are too informal and ad hoc for such a critical step in system development. We have therefore developed a systematic method of component identification and boundary definition as well as component specification. This systematic approach leads to decreased total cost of ownership and rapid software development life cycles by reducing ambiguity and increasing traceability back to business goals and processes.Mapping a business architecture to a component-based software architecture. 45ith the growing trend of building component-based architectures in many organizations and the recent interest in using Web services, system architects face three fundamental design decisions: What services should be exposed as public Web services to be accessed by clients and business partners? How should largegrained enterprise-scale components be identified and specified? How should the internals of a large-grained component be designed? Here, we address these design decisions, discuss the methodology aspect of component-based development and integration (CBDi), and present extensions to current OO analysis and design methods in order to support component-based and service-oriented software engineering. Our focus centers on using a business-driven approach for component identification and specification within a highly reconfigurable component-based architecture. This approach centers on the initial stages of the analysis of a software system within which a goal-oriented model of a business is created and developed into a business architecture. We will demonstrate how the business architecture thus developed is mapped onto a component-based software architecture (CBSA). The procedure can be considered an extension and refinement of the Unified Process of Software Development (see www.rational.com/q1/rupov.jsp) and ...

Service Oriented Architecture (SOA) is emerging to be the predominant architectural style of choice for many organizations due to the promised agility, flexibility and resilience benefits. However, there are currently few SOA metrics designed to evaluate complexity, effort estimates and health status of SOA solutions. This paper therefore proposes a SOA metrics framework which includes both service level and SOA-wide metrics to measure design and runtime qualities of a SOA solution. The SOA-wide metrics predict the overall complexity, agility and health status of SOA solutions, while service level metrics focus on the fundamental building blocks of SOA, i.e. services. The combined views deliver a compelling suite of SOA metrics that would benefit organizations as they consider adopting SOA. These metrics, which are based on observations of many SOA engagements, are illustrated through a case study that describes a recent ongoing project at IBM where SOA was utilized to build the solution assets.