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.
I had a chance to go "Speedjamming" at RSC 2009—which is the marketeers' way of letting me talk to the sort of real internal gurus who sometimes aren't allowed out around press or analysts unsupervised. This gave me a chance to meet Ian Charters, IBM Distinguished Engineer, Rational, and get a traditional IBMer's take on EA. I also attended Ian's presentation entitled "Enterprise Architecture : putting the "A" in Business Process Management" which, thankfully, was very much in line with Greg's views, above. In IBM terms we have two kinds of architects: first, the Enterprise Architect, who deals in abstractions and things that are always changing, who uses a generalised tool like System Architect and who is comfortable with "knowing something about everything"; then there is the Solution Architect (perhaps called a "designer" outside of IBM) who deals in specialist areas such as BPM and SOA frameworks and who uses specialised tools such as Rational Composer or Rhapsody and who is only happy when knowing "everything about something".
You can express this in a 2d "2x2" model, showing aspects of a project relevant to the 2 kinds of architect—and then add a third dimension corresponding to the business, IT systems and technology planes of the overall conceptual model. This view seems to describe a landscape over which various players travel and which helps you co-ordinate the activities of all the stakeholders in a business system so as to deliver something holistic, "the right thing, done right". You can think of BPM (Business Process Management—or Modelling) as being about "doing things right", while high level EA is about "doing the right things", although I think you could also view BPM as simply part of holistic EA "doing the right things and doing them right". OK, so that's just a taster—luckily there is a published paper which goes into the details, here.
However, a somewhat unrelated part of our speed jamming chat was about the need for more professionalism in IT. Sure, I've met people who've become real experts just through experience—but you'd be amazed at the holes in their knowledge sometimes, which I've spotted through being a techie too (try talking about directories to a self-taught Netware 3.11 guru), but how could a business user have seen them? I knew about directories because I have a rather rusty Netware 4 CNE qualification and a business user could recognise that (and ask when I last recertified) without needing to know much about Netware.
Ian is quite proud of his "distinguished engineer" status—because he had to earn it, with assessed courses as well as with "in the field" experience. In fact, Ian and I's first point of contact was when we both agreed that the proof point for IT professionalism was when IT professionals routinely expected to take out professional indemnity insurance. What other "profession", besides IT, allows you to make a mess of things, put an extra check mark on your CV and move on unscathed? Well, banking, perhaps.
I also had an interesting Speedjam with Geoffrey Clemm (Distinguished Engineer, Configuration and Change Management, Rational Software). He's the guy responsible for bringing the 3 (or more) Configuration Management tools IBM has post the Telelogic acquisition (and its Jazz initiative) into one whole—in fact, he welcomed Telelogic as it gave him the ammunition to convince IBM to do something about integrating IBM's configuration management story.
What he seems to have come up with is a federated view. The Jazz platform with Team Concert (and or Subversion and other 3rd party tools) provides an agile development SCM and defect tracking facility, with instant messaging collaboration support and all the other trendy nice things. Then, (extremely non-trivial) connectors asynchronously synchronise with a Requisite Pro back-end that provides heavyweight audit and regulatory support across the Enterprise if you need it—and manages collisions between agile teams working on parts of the whole....
I need to look at this in more detail, but it seemed an attractive attempt to get the best of both worlds, to me - Geoffrey struck me as very much an engineer, not a marketroid. That's the good side of IBM analyst relations, we get to talk to people who actually write IBM technology, with no marketing controls/supervision; beyond the fact that long term IBM people really do believe in IBM—but the Telelogic infusion seems to have stirred them up in a very good way. I wonder if readers have any views on this sort of approach to a "federated CMS"? I asked Robert Cowham (chair of the BCS Configuration Management Specialist Group, which has just held a successful "Pragmatic Configuration Management for IT Services—Reducing Cost and Risk" conference with the ITSMF) and he said that he'd gained a similar understanding of IBM's approach to integrating its old tools with Jazz—but that it does all depend on those connectors!
Finally on Day 2 Richard Crisp (see my RSC day 1 iRise, just across the aisle from Ravenflow in the RSC Exhibit Hall, has a part to play but whereas Ravenflow is an algorithmic transformation of a word document into UML, as far as I can see, the iRise product suite is a much more qualitative, illustrative effort. Perhaps the two should share technology—although I have to say, from talking to both at RSC, this seems rather unlikely.
Now RSC is coming to England on the 12 and 13 October at the Grange St Paul's Hotel, London.
Blog Tag: RSC2009