02 October 2009

Democratization of Architecture

Many IT professionals know they should do their architectures. How can you build a system, or preferably a capability, without an articulated architecture to backstop it? But UML is a complex inscrutable art. The tools to weild it can be daunting. So very few IT professionals, going by the name architect, actually build them. Most times, when built, they are a snapshot of whatwas wanted and are sent to the bookshelf to live out a long life.

It is with this as context that we undertook an effort, about 6 months ago, that we now understand as 'the democratization of architecture' - making it safe for the masses. The gist is that we wanted to accomplish 2 things:
1. Lower barriers to entry
2. Make IT capabilities more accessible at design time

Using a simple spreadsheet input approach we eased the entry barriers into a real UML tool, Rational Software Architect (RSA). Now we can consume customers' mission elements via a simple excel spreadsheet breakout. Customers sit with client personnel and talk about their 5-7 major mission elements that they need in the solution. Next they break each of those down to its constituent parts, and so on down to 4 or 5 levels of detail. RSA consumes these mission elements and produces a strategic mission model - simple, done!

On the IT capabilities side, we've done a market survey. For each of the major IT capabilities groups, e.g., Security, User Experience, Development Tools, Information Managment, Transactional Management or Enterprise Service Management. See pic below


.Basically all the horizontal middleware capabilities, we build simple models. These models were labelled using the customers' vernacular - the way they talk about these capabilities.

Now that we have consumed the mission elements & have resident the IT capabilities, we can produce a simple set of spreadsheets, one for each IT capabilties group. However, we can also put in juxtaposition, to the IT capabilties, the mission elements.






See pic for service management example of RSA produced spreadsheet that maps mission elements (columns) against the IT capabilities (rows). This simple form allows the user to sit with a client person and map IT capabilities, that could satisfy requirements, against the corresponding mission elements.

The cells, where IT capabilties and mission elements intersect, is where we note the correspondence. A simple x in the intersecting cell is all that is needed. Now, if we have a statement about that relationship, then that can be easily entered, in the cell, and will show up on the actual UML model. Once the six xlses are filled out (reference 6 pieces of the core above) then using a simple RSA plug-in (authored by Fred Mervine, the Grandaddy of this Democratization effort) we re-c0nsume the IT capabilities crossed with mission elements and produce a UML joint capabilities diagram. Essentially we join the mini-models from each sheet into one overall model that shows the collection of relationships. UML was never this easy (for the client).

A real UML jock, at this point, can take that joint capabilities diagram and decorate it with NFRs, sequences, and other essential architectural elements and produce a final actionable architecture. However, what we've done is to ease the process of IDing the basic mission elements in the solution and IDing the basic COTS architectural elements needed to satisfy those requirements. Architecture for everyone.






10 August 2009

SOA Ecosystem & Sets of Systems

As net-centricity becomes a common term and SOA moves into its productive phase we increasing see sets of systems coming together. The tendency is to take the term system and extend it to 'System of Systems' SoS. However, I'll argue that this approach takes the hyper-specified method of defining and engineering a system and imposes it on a set of systems. Gone are the days where the world moved so slowly that requirements stayed put long enough to waterfall a system out. Now that the global village is hyper-connected change occurs in real time. We need a new method by which we conceive of and implement sets of systems. Even sets of systems themselves are being linked together. Organizing principles change as we go up the hierarchy of sets.

If I join 5 systems together I can not do so rigidly like they were built. One system can be built to clearly define its inputs and outputs & its behavior given them. However, once I conjoin several systems I must live with the randomness of their individual operations. It is not random in the sense that it is unpredictable - they are, after all, computer systems. Their individual behavior is random in respect to the goals of the set. This means that the operational rules of the Set of Systems (SetOS) must be at a higher level of abstraction than the individual systems. The SetOS must scavenge resources when it can get them and offer back, to the individual systems, resources as they may take advantage of them. The term loose coupling has been used for this kind of idea, however I believe this term misleads. It is all about the focal point. Loose Coupling puts the focal point back on the individuals systems - which are loose coupled. We need to pan out. We must come up with a language about sets.

Set talk makes people uncomfortable. It is the pluralistic nature of such talk that disarms us. How do we conceive of system operations (a system like Gregory Bateson would use it) that apply to the whole set of constituent systems? An ecosystem is a good model for such things. Sets of individual actors interplay with each other according to operational principles that show behavioral organization at a higher level. Using SOA as an example. We can have individual SOA-based systems but it is only when the aggregate decide to collaborate that you actually see useful cross-program services begin to populate the enterprise registry. A group of ACAT 1 program managers who all, individually, implement SOA will never place one useful service in the enterprise registry. It is only when these individual operate as a set of PMs that we begin to see the benefits of SOA as an ecosystem enabler.

SOA is not dead, but the ACAT 1 acquisition system is trying its hardest to kill it off. SOA will continue to shear at the cultural & programmatic aspects of our acquisition system until the SOA ecosystem arises. There are interesting examples where it is beginning to happen. Portfolio owners are beginning to see that they can organize across their SetOS to drive a higher level benefit. This benefit is almost always to the greater good and echews the hyper-specific needs of individual programs.

04 June 2009

AFEI.ORG Industry SOA Acquisition Reform Recommendations

(See attached file: SOA_Acquisition_Final_Report.pdf)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -

Ooops, for some reason Blogger didn't clip it, so let's try this:
http://www.afei.org/whitepapers/SOA_Acq/SOA_Acquisition_Final_Report2.pdf
Let me know if you an access it without being surveymonkeyed with.