Sorry it has taken a while to get my second report on RSC 2009 out—it's turning a braindump into respectable reportage that takes the time, I find.

On Day 2, I was pleased that in the "Innovation for a Smarter Planet" keynote, in which Steve Mills (IBM Senior VP and Group Executive IBM Software) and Grady Booch (IBM Research Fellow) stressed the opportunities and Utopian prospects (if we do things right) for a world in which "everything" is identified and connected, Al Zollar (General Manager of IBM Tivoli) had a significant slot, explaining the importance of managing all the myriad "intellectual property", software and hardware assets this Utopia will hold.

I'm just glad that Tivoli really seems to be an equal player with Rational in IBM—as, after ITIL v3, I think that the relative importance of Operations in the IT world is due to increase. After all, it's Operations that actually manages the delivery of ROI from technology, as a new computer program or clever piece of hardware delivers nothing to the business until it is installed and used. I've always thought that Tivoli should be part of the Rational brand—or, perhaps, Rational should be part of Tivoli—as many Rational and Tivoli products, notably Rational Asset Manager and Tivoli CMDB, must work together to provide the foundation for IBM's part of the Smarter Planet.

I had an interesting chat with Greg Sikes (Director, Enterprise Architecture and Systems Modelling, IBM Rational software), following on from his Actionable Architecture for the Smarter Enterprise keynote on Day 1. I am very much of a believer in "actionable" EA. In other words, that an EA model is no value unless it is actually of practical use (and seen to be of use) to someone other than Enterprise Architects. Which involves managing the expectations of all the stakeholders in EA, including people like Human Resources and the CEO's secretary, as well as managing the EA assets.

The scope of an EA model is greater than just an IT system, but parts of it should transform into IT systems; although other parts could transform into, say, organisation charts used by managers; Business Process Models; and so on. But there usually isn't just one EA model and one Architect—or even one tool. An EA model, or models, in something like Rational System Architect defines a context in which, say, corporate data models (using an Entity Relationship Diagramming tool), IT system models (in UML2, say), business models (in Websphere Business Modeller, for example) or even Organisation Charts (in Visio, perhaps) fill in the details.

However, IBM now has two new EA modelling tools from Telelogic (where Greg Sikes comes from): IBM Rational System Architect for Enterprise Architecture in the context of Business Process Management and IBM/Rational Rhapsody for model-driven development for real-time, embedded or technical systems—and software development generally. Plus, IBM had its own EA practice before the Telelogic acquisition (plus Rational Rose, which had systems engineering and some architectural capabilities), although as Ian Charters (IBM Distinguished Engineer, Rational; of whom more later) admits, IBM didn't have a really effective EA modelling tool until System Architect arrived.

Nevertheless, I could find the choice between System Architect and Rhapsody rather confusing, because EA as I understand it extends well beyond the technology context. Top level EA abstractions don't really care whether a process is implemented in hardware or software—or a manual process—although it is, as I've said, important that EA models transform, with additions, into working business process and technology implementations. So, why shouldn't parts of an System Architect EA model become embedded systems in hardware—and if they do, must Rhapsody be involved on the way? And, if Rhapsody is designing an embedded system and the associated software, can it handle the manual processes in which it is used and their organisational context?

So I asked Greg to clarify: "Enterprise Architecture, supported primarily by the System Architect product, is about "Architecture for Planning" while Rhapsody is about "Architecture for Building". That really sums it up, I guess

Greg goes on to say "Enterprise Architecture provides the ability to clearly communication strategies and objectives to the organization; EA allows organizations the ability to understand how hardware and software assets are used by the organization (roles) and processes they use to run their business. Understanding is certainly valuable, but the real value of EA comes with actionable architecture—the ability to investigate multiple future architecture scenarios and understanding the impacts to assets, organization and process before making the changes".

And Rhapsody, Greg says, "is about model-based systems and software design and development. Product architectures and behaviours can be created and explored in Rhapsody prior to being built. The real power of Rhapsody comes with systems that have embedded software—Rhapsody can help our customers design software in a platform independent manner and later on, implement software on specific target platforms".

In the integrated scenario he continues, "Architecture Plans (in EA) are handed downstream, either between companies in the supply chain or within a single entity, to the Build team that continues putting meat on the bones with eye towards product development". Good, I feel very happy with that clarification.