yet another SOA conference

Bullets from March 31, 2009 Software Engineering Institute and IBM Conference “Embracing Change: New Technical Approaches to Federal IT” Washington DC

On March 31, 2009, in Washington DC (well, actually, in Arlington, Virginia), I attended yet another SOA-related conference. I am finding it is too easy to get bogged down in conferences, symposiums, workshops, seminars, communities of practice, and other meetings of various sorts and that at some point “real work” must be done so I am only going to post some bullets and perhaps a couple of images for what for me were some of the highlights. Due to time constraints, my narrated comments must be kept to a minimum. Note: Northrop Grumman was mentioned a couple of different times throughout the conference. Northrop Grumman was noted as being a co-leader of work and findings produced by the National Defense Industrial Association (NDIA) Association for Enterprise Integration (AFEI).
One of the most interesting points is that it was mentioned that the role of a “Prime System Integrator (SI)” is being/needs to be deconstructed and reassembled (loosely coupled). The Prime SI should no longer be a “silo”.

Governance is primarily concerned with policies and procedures, roles and responsibilities, and both design time and run time management. SOA governance provides a set of policies, rules, and enforcement mechanisms for developing, using, and evolving SOA assets and for analysis of their business value. It provides the who, that what and the how decisions business, engineering and operations are made in order to support a SOA strategy.

Linda Northrop of SEI gave a presentation on software product lines (SPLs), defined as “set of software intensive systems sharing a common managed set of features that specify the specific set of features that specify the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way”. (What a mouthful!) SPLs have a technical side (architecture and production plan) and a business side (scope definition and business case).

Core assets include:
• Requirements
• Domain models
• Software architectures
• Performance engineering
• Documentation
• Test artifacts
• People and skills
• Processes
• Budgets, schedules, workplans
• Software

Northrop also introduced software product line practice areas.

From the SEI website (http://www.sei.cmu.edu/productlines/index.html )

To achieve a software product line, you must carry out the three essential activities described in Product Line Essential Activities: core asset development, product development, and management. To be able to carry out the essential activities, you must master the practice areas relevant to each and apply them in a coordinated, focused fashion. By "mastering," we mean an ability to achieve repeatable, not just one-time, success.

A practice area is a body of work or a collection of activities that an organization must master to successfully carry out the essential work of a product line. Practice areas help to make the essential activities more achievable by defining activities that are smaller and more tractable than a broad imperative such as "develop core assets." Practice areas provide starting points from which organizations can make (and measure) progress in adopting a product line approach for software.

This framework defines the practice areas for product line practice. They all describe activities that are essential for any successful software development effort, not just software product lines. However, they all either take on particular significance or must be carried out in a unique way in a product line context. Those aspects that are specifically relevant to software product lines, as opposed to single-system development, are emphasized.

SEI has documented the following information per practice area:
• An introductory overview of the practice area
• Aspects of the practice area that apply especially to a product line, as opposed to a single system.
• How the practice area is applied to core asset development and product development, respectively.
• A description of example practices that are known to apply to the practice area.
• Known risks associated with the practice area.
• References for further reading

Since there are so many practice areas, they have been organized for easier access and reference, divided loosely into three categories:
• Software engineering practice areas are those necessary for applying the appropriate technology to create and evolve both core assets and products.
• Technical management practice areas are those necessary for managing the creation and evolution of the core assets and the products.
• Organizational management practice areas are those necessary for orchestrating the entire software product line effort.

Each of these categories appeals to a different body of knowledge and requires a different skill set for the people who must carry them out. The categories represent disciplines rather than job titles.

Software engineering practice areas are those necessary for applying the appropriate technology to create and evolve both core assets and products. They are:
• Architecture Definition
• Architecture Evaluation
• Component Development
• Mining Existing Assets
• Requirements Engineering
• Software System Integration
• Testing
• Understanding Relevant Domains
• Using Externally Available Software

Technical management practices are those management practices that are necessary for the development and evolution of both core assets and products. They are:
• Configuration Management
• Make/Buy/Mine/Commission Analysis
• Measurement and Tracking
• Process Discipline
• Scoping
• Technical Planning
• Technical Risk Management
• Tool Support

Organizational management practices are those practices that are necessary for the orchestration of the entire product line effort. They are:
• Building a Business Case
• Customer Interface Management
• Developing an Acquisition Strategy
• Funding
• Launching and Institutionalizing
• Market Analysis
• Operations
• Organizational Planning
• Organizational Risk Management
• Structuring the Organization
• Technology Forecasting
• Training

In other parts of the conference, it was suggested to grow the architecture of a system through incremental and iterative development.

Grady Booch made a presentation via Second Life. He didn’t indicate where he was this month but he did indicate that this month he had been in China, Vietnam, and Texas. An older version of the presentation he gave is available at: http://www.booch.com/architecture/blog/artifacts/Software%20Architecture.ppt
References were made to the books “Organizational Patterns of Agile Software Development” and “Enterprise Architecture as Strategy: Creating a Foundation for Business Execution”.

Conway’s Law was mentioned. From wikipedia.com, “Conway's Law is an adage named after computer programmer Melvin Conway, who introduced the idea in 1968: “...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”. “Despite jocular usage and jocular derivative "laws," Conway's law was not intended as a joke or a Zen koan, but as a valid sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.””

A completion date is not a point in time; it’s a probability distribution.

Four patterns of success:
• Scope management -> asset-based development
• Process management -> right-sizing the process
• Progress management -> honest assessments
• Quality management -> incremental demonstrable results

http://www.wwisa.org
http://www.sei.cmu.edu/pub/documents/08.reports/08tr006.pdf

Mike Konrad stated that “good governance requires a responsible and empowered IT workforce. Necessary freedoms include:
• Freedom of speech
• Freedom to change
• Freedom to experiment
• Freedom to create
• Freedom to adapt
• Freedom to distribute
• Freedom of computing power
• Freedom to demonstrate

Evolution of IT:
• Subroutines 1960s
• Modules 1970s
• Objects 1980s
• Components 1990s
• Services 2000s

SOA certification is available through SEI: http://www.sei.cmu.edu/certification/soasmart.html