Early on in my EA career, I was very fortunate to become involved in a pioneering EA initiative at Westpac. My introduction to Westpac came when I helped its Group Data Resource Management team develop tool and repository support for its enterprise business model. During this engagement, I kept hearing people refer to an exciting but very hush-hush project that went under the code name “CS90.” I was intrigued and determined to find out more. That proved very difficult because the project was so leading-edge and innovative that all its documentation was marked at the highest level of secrecy. To make it even harder for competitors to find out what Westpac was doing, CS90 was divided into four teams, with very few people knowing what the whole thing was about.
In my second stint working with Westpac, I was in an extremely privileged role. The Australian Government offered incentives for companies that increased overseas trade, so Westpac wanted to sell the intellectual rights for CS90 (Core Systems for the 1990s). I was engaged as an enterprise architect to provide a detailed overview of CS90 so it could be presented to potential buyers in the US and Canada. The audience was mainly financial institutions and IT vendors.
I found that only six or seven people were privy to the big picture that showed how CS90 worked. In effect, there was plenty of detailed design going on, and it all made sense within an overall architectural context — but the enterprise architecture was largely hidden under the veil of secrecy. To reveal the enterprise architecture behind CS90, I had to deconstruct countless documents, papers, diagrams, and other artifacts from each of the ‘big four” project areas. I was fortunate to have two large offices at the time; in one of those, I created something that rapidly became known as “the wall.”
From the ceiling, I started with pages outlining the strategic business directives and requirements. Below this, came more formal statements of the requirements. To one side, there were principles and policy documents. On the other side, there were roles and responsibilities within the four project teams. At the very bottom of the wall — at floor level — were the detailed solution designs for the components that comprised CS90. In between, there were specifications for procedures, transactions, business rules, terms and conditions, products, workflows, software modules, and frames. In essence, I had created a hands-on visualization showing every type of artifact in the development process. As such, this endeavor emphasized to me the vital importance of version control and traceability for any EA project.
The first point gleaned from my experience is that EA provides a unique perspective that I call architectural thinking or architectural understanding. In other words, everything that we examine and propose is described in terms of its basis within an enterprise architecture.
Architectural understanding informs and guides everything that we do to manage the evolution of an enterprise architecture, but our architectural thinking is often challenged or changed as we pass through the solution or design stage and the development or implementation phase. And then even at the operational or systems level, when we realize our architectural plans, they are still prone to additional workarounds and fixes. These levels of constraint on our architectural thinking are shown in Figure 1, in something that I call the levels of architectural understanding (these layers resemble my CS90 wall).
What does this tell us about architectural versioning? It tells us several important things. It tells us that we need to keep track of versions of our architectural thinking by versioning artifacts at the architectural level. Beyond that — at the solution (or design), development (or implementation), or operational (or systems) levels — it becomes the responsibility of other teams to track versions of their work products and outputs.
Architects should not be involved in versioning these deliverables, but they must maintain a trace from artifacts that provide architectural direction and guidance to outputs at the lower levels. By maintaining this trace, architects can monitor the additional constraints and requirements placed on architectural thinking at these lower levels, which is one of the main ways where we identify the need for further evolution of EA. The two key points are (1) the need to focus thinking at the architectural level and (2) the need to maintain a trace rather than take the additional responsibility of versioning objects at the other levels.
[For more from the author on this topic, see “Architecture Versioning.”]