Thursday, April 2, 2009

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

SOA Consortium in Washington DC

On March 25 and 26, 2009, in Washington DC (well, actually, in Crystal City, Virginia), I attended the first SOA Consortium conference for the year 2009. The Service Oriented Architecture (SOA) Consortium is an advocacy group. When the group formed, to expedite and gain infrastructure efficiencies, , the group’s founding sponsors and members decided that it made fiscal sense to be managed by the Object Management Group (OMG). Therefore, the SOA Consortium always cohabitates with OMG; however, these organizations have completely different missions. For one, the SOA Consortium does not do standards work. The SOA Consortium members are a mix of end-users (mostly Fortune 200), vendors and service providers. The group’s mission is to simply evangelize SOA in the context of business value generation and to enable successful (and sustainable) SOA adoption. The organization’s website is: http://www.soa-consortium.org.

I discovered this group about a year ago. In this group, I have met many of the SOA gurus whose work I have been following for the past few years: gurus such as Thomas Erl (whose latest book published in December 2008 I have yet to read even as it sits on the banister by my front door as a constant reminder to be picked up), David Linthicum, Richard Mark Soley, and others. I discovered yesterday that a set of Enterprise Service Bus (ESB) criteria and evaluation reports that I have found useful the last several years when comparing ESB products was actually written by Brenda Michelson, a woman with whom I have been engaged in conversation over the past year. Yesterday I also met one of the two co-founders of ZapThink, and the creator of a well-known SOA poster which I have seen papered on several colleagues’ office walls (including my own on occasion). In spite of the popularity of some of the members of the consortium, I have found that the meetings tend to be quite small (always less than 30 people and usually more like a dozen). Because of their coziness, these meetings have given me the opportunity to have good discussions with authors, industry analysts and presenters, methodologists, bloggers, professors, business executives, vendors, product/methodology trainers, and other highly credentialed SOA evangelists.

The March 2009 meeting started with a brief introduction by Dr. Richard Mark Soley, Chairman and Chief Executive Officer of OMG. David Linthicum, Northrop Grumman's very own Scott Tucker’s brother-in-law, is an internationally known author and application integration and SOA expert. He spoke of the intersections between SOA and Cloud Computing. The gist of his argument was that it was imperative that we each start to elevate the importance, experimenting and adoption of cloud computing. Next, Sandy Carter, author and Vice-President of IBM’s SOA and WebSphere Strategy spoke on how SOA can help in today’s tough economic climate. Sandy’s latest book is “The New Language of Marketing 2.0 – How to Use ANGELS to Energize Your Market”. The title of the book is kind of funky but is an acronym for her marketing approach:
• Analyze and ensure strong market understanding
• Nail the relevant strategy and story
• Go to Market Plan
• Energize the channel and community
• Leads and revenue
• Scream!!! Don’t forget the Technology!

You will have to read the book (or at least quickly scan it on amazon.com) to learn more about her marketing approach and I guess to have her acronym make sense. I do not consider myself a salesperson although that really is at least *part* of my job description. However, I need to pay more attention to the technical side of this SOA story. I have long been sold on its business case.

Speaking of books, another book I heard about was “SOA Governance” by Todd Biske. This is yet another book on SOA on which I will have to at least peek.

After a morning break, we attended a roundtable discussion on SOA in a Green World. Brenda had mentioned this in a previous teleconference, and, while “green” is today’s color of choice, I am yet to be convinced that there is a strong connection between SOA and its potential promise to avert climate change.

Carter pointed out that economic conditions are causing businesses to take a harder look at the efficiencies of their processes. Carter suggested that a byproduct of that scrutiny will be greater energy savings in IT and other parts of companies. Linthicum agreed that SOA and cloud computing will deliver more efficient, and thus, greener processes. However, he added, green is a byproduct of process automation or improvement, not the reason for adopting new approaches.

Someone commented that as we endeavor to make IT “greener,” we should weigh the benefits that IT has already brought to the planet. For example, how many trees have been saved due to paperless processing, Electronic Data Interchange (EDI), and online communication? How much oil and energy has been saved because of telecommuting and teleconferencing? How many stores and shopping malls have not been built due to the rise of electronic commerce? And what about the economic benefits that IT has brought? For example, how many people no longer needed to be uprooted from their communities in order to attend good schools and universities or get a good job? Thus, while SOA can play a leading role in the greening of our world, we need to understand how many resources have actually been saved, and gained, as the physical world has been displaced by the digital/virtual world – probably far more than the energy that computers have consumed.

By the way, in 2008, a group formed who call themselves the Green Computing Impact Organization (GCIO). This group is managed by The Object Management Group and works with the BPM Consortium and the SOA Consortium. This group’s website is at http://gcio.org. This group’s mission as stated on their website is:
“Be an active participant in transforming the enterprise business community from an environmental liability to an Earth conscious example of responsibility. We do so through our collaborative membership programs and initiatives which bring together enterprise business and IT executives, visionaries, pundits, authorities and practitioners all with a vested interest in the promotion and adoption of sustainable business practices. As a community, our members and sponsors provide the foundational information a company needs to make business sustaining and environmentally responsible decisions and directions. We work with all facets of industry and government operations as well as educational institutions and complimentary non-profit agencies.”

Cory Casanave, Board of Directors at OMG, President at Model Driven Solutions, Inc., in Vienna, Virginia, and a leader in Model Driven Enterprise Architecture (MDA), SOA and Semantic Web, introduced a new template (or profile) extension for UML called SOA Modeling Language (SoaML). Yes, another modeling language! The SoaML (it bothers me a bit to type Capital “S” with lower-case “oa” as I am so accustomed to typing “SOA” in all upper-case) is defined as a “specification [which] describes a UML profile and metamodel for the design of services within an SOA”. According to the agenda: “The SoaML profile supports the range of modeling requirements for SOA, including the specification of systems of services, the specification of individual service interfaces, and the specification of service implementations. This is done in such a way as to support the automatic generation of derived artifacts following a [Model-Driven Architecture] based approach.” My only thought on this is that this is yet something else to be explored.

JP Morgenthal presented an interesting yet, for me at least, a somewhat irritating talk on the relationship (or lack thereof) between SOA and Business Process Management (BPM). Morgenthal, a senior analyst at the Burton Group and former chief architect at Software AG, suggested that the industry has placed too much emphasis on the relationship between BPM and SOA. He felt that the two were completely unrelated and one did not necessarily help the other and that the two didn’t even need to be considered in parallel. I listened to his rant and told him that I disagreed with his thesis. In general, he seemed to enjoy being the contrarian and I had the feeling that any notion that any two or more people agreed on, he would have enjoyed playing the devil’s advocate. A little side argument that arose was the distinction of enterprise SOA and non-enterprise SOA. When does something indeed qualify to become true “enterprise-level” SOA?

A few vendors (less than a dozen—I didn’t get too many chances to freshen my ink pen collection) had booths. Among these was a booth for MagicDraw advertising an announcement dated March 23, 2009: “Cameo SOA+ 16.0 beta 1 is released”. See the following for more information: "Newly released Cameo™ SOA+ leverages the latest Model Driven Architecture® (MDA® ) standards and technologies making the transition from model to implementation highly automated, reducing implementation and maintenance costs. Cameo™ SOA+ supports all standard SoaML diagrams. Cameo™ SOA+ is packaged as a plugin to the MagicDraw® tool and is available for purchase separately. The Cameo™ SOA+ retains all capabilities of award-winning MagicDraw architecture modeling environment adding a SOA specific perspective."

I did grab a copy of the latest trial version of Enterprise Architect and as assortment of white papers and other materials. Guess I did not fully do my job as being a green SOA Consortium member since I took these printed materials. I grabbed two business cards for Northrop Grumman’s Stanley King, an engineer who works in the area of first response management. NEC Sphere Communications, showed a compelling demo of web 2.0 technology in a first responder scenario.

An important thing to note is that the SOA Consortium has been working on developing what they call a “Business-Driven SOA Planning Framework”. The goal of this framework is to identify the major business-driven SOA activities and to provide guidance on planning and executing those activities.

The next SOA Consortium is one I would really love to attend but imagine will have a hard time selling to my manager as it will be held at the Real InterContinental Hotel on June 24 and 25, 2009, in San Jose. That is San Jose, Costa Rica; not California.