IRM UK’s Enterprise Architecture Conference took place in London earlier this week. I only had time to attend the second day of the seminar on June 10, but one day alone provided plenty of stimulation, new ideas and good contacts.

The opening keynote of the day was given by John Zachman himself, the Grand Old Man of Enterprise Architecture. Unfortunately, I missed the first half-hour of his presentation, as London underground was on a strike again. Then again, Zachman went 15 minutes or so overtime, so I was still able to enjoy 45 minutes of his loud and — as he said himself — dogmatic presentation. His main message was — not surprisingly — that architecture is architecture is architecture: it is not the result, not the implementation, not the instance; architecture is the set of descriptive representations to describe a complex object so that an instance of the object can be created and changed. These representations, according to Zachman, typically include abstractions such as (and answering questions of) bills of material (what), functional specifications (how), drawings (where), operating instructions (who), timing diagrams (when) and design objectives (why). There are also different perspectives to architecture (by different stakeholders): scope boundaries (strategists), requirement concepts (owners), design logic (designers), plan physics (builders), part configurations (implementers) and the product instances (operators). The Zachman framework, based on these abstractions and perspectives, is an ontology, not a methodology. These core tenets of the Zachman framework have not changed for decades. Characteristically, Zachman presented his slideshow on real foils rather than on computer.

After the break, I went to the EA Methods and Approaches track featuring Paul Allen’s (Cutter Consortium) presentation on business capabilities. Allen defines capability as “a combination of capacity and ability to perform a coherent family of functions in terms of what must be done to achieve stated outcomes”. Thereby, he makes a clear distinction between a capability and a service, which he defines as “software functionality that must be specified in a business context and in terms of contracts between the provider of that functionality and its consumers”. Allen maintains that business = set of capabilities. The relevance of capabilities increases as business processes are standardized and integrated. Also, in today’s renewed focus on cost cutting, resources should be focused on value-adding activities. Clearly specified capabilities help in “recalibrating” business accordingly.

Next, I changed to Sponsor Insights track, in which I attended to the session entitled “Actionable Enterprise Architecture: Helping organizations do the right things right, right?” by Ian Charters of IBM. He made an important distinction between “Upstream EA” and “Downstream EA”. Upstream EA is about identifying, funding and resourcing the most important programmes, in line with the business trategy and within the investment budget, in the right sequence, and with effective programme management and control. This requires good “models”, capable of portraying the overall “as is” and “to be” architectural landscape. Downstream EA ensures that the solutions delivered by the programmes meet the needs of the business, work within the existing IT environment and contribute towards the realisation of the enterprise’s IT strategy. This requires easy-to-use, easy-to-find standard components such as patterns, architectural building blocks and princples in a catalogue-like format. Together, the two approaches constitute “actionable EA” that combines “good navigation” upstream with “good engineering” downstream.

After lunch, Steve Jones of Capgemini gave a keynote about what is happening in business, technology and solutions today. In the wake of Web 2.0 and Cloud Computing, life has got a lot more complicated, Jones said. In addition to traditional IT of transactional applications and machine-oriented computing within the enterprise boundaries, there is now virtualization in terms of grid and cloud computing but also a new paradigm of “interactional applications” and people-oriented computing. Both types of IT need to be architected. Jones addressed the IT audience and urged it to proactively decide how to apply the new technology in the cloud, because either the shadow IT is “with you” or it is “over you”: people will use IT beyond the firewall anyway.

Back in the EA Methods and Approaches track, the session by Roger Sessions, CTO, Objectwatch provided insights into how to manage the increasing complexity of enterprise architecture. On the lookout for Factor X that would explain the increasing number of IT failures and troubled IT projects, Sessions identified complexity as the most likely candidate. But why would complexity have increased so much in such a short time (30-35 % a year in the last two years)? Two answer this question, Sessions turns to Glass’s law: “For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity”. Applied to IT systems, for every 25 percent increase in business functionality, there will be a 100 percent increase in system complexity. As the means to address complexity, Sessions suggests his method called Simple Iterative Partitions (SIP), in which a complex system is requisitely partitioned to smaller subsystems with less overall complexity.

There are two components of IT compexity: the number of business functions in a system, and the number of connections to other systems. In a monolithic system, all complexity pertains to the number of business functions, as there is no communication between systems involved. In a SOA with one service for each business function, all complexity comes from the number of connections between the services. An optimal partitioning is a tradeoff between the two types of complexity and lies somewhere between these two extremes. SIP is a mathematically grounded methodology for arriving at this least complex solution. Sessions maintains that simple solutions result in 50-90 % reductions of IT cost. A very compelling proposition, indeed!

As the last presentation of the day, I opted for Charles Edrwards’ “Agile Enterprise Architecture: A step change is required”. AgileEA! is a free open source framework for EA Operational Process. It is an interesting blend of Agile ideas taken from software development, Enterprise Architecture ideas from multiple sources, an Operational Process for EA’s to follow, and Maturity ideas to run EA while also maturing EA in an organisation. The framework addresses the necessary step changes to get to the next level of Enterprise Architecture:

  • Agility and Adaptiveness — speed and time
  • Pragmatism & Urgency — Ease of starting & quick results
  • Structure & Rigour — What does a good EA look like?
  • Integrated — concepts & support Tools
  • Openness — Bringing all the puzzle pieces together
  • Cultural — People & awareness make the change happen
  • Architectural implications — Enterprise Technical Debt

JJK at EAC
It was a nourishing day with lots of food for thought. I look forward to EAC 2010 and hope that I will able to attend the entire conference the next time around.