In my previous organisation I delivered a basic but functional baseline architecture for the enterprise. It didn’t go down into a vast amount of detail, but it was robust enough to use with stakeholders to highlight the complexity of the current state of technology and applications, as well as the amount of change that the organisation was proposing.
Having worked at the organisation for 12 years, a fair amount of that knowledge was in my head, or in the heads of the other members of the Architecture team. This enabled us to build a very high level design using white boards and post-its. What I wanted to cover here can either be seen as the second phase I completed in my previous role, or the situation I find myself in now, a new organisation where I have limited knowledge of the underlying architecture.
In trying to wrap my head around this new organisation I have taken the opportunities offered me by ArchiMate 3.0, the Archi 4 beta and the time afforded a new role to learn. In building up my knowledge I have taken the following approach.
Build Baseline Architecture
Building a baseline architecture has value within an enterprise, however it can be expensive and time consuming. The process stated here works for me and allows me to build up a more complete picture of the enterprise as I gain knowledge of the current systems.
Ideally a scope is set for each iteration, for instance, I have been assigned a small task to understand the current limitations within the BYOD solution, and with this have begun building up my baseline.
I have broken up this process into several smaller sub processes/steps.
For all their disarray, IT Departments are generally good at holding onto their technical documentation, at least for when a project first went live, if not the changes beyond it. Whether this is stored in Google Drive, Microsoft SharePoint, or even just a number of documents stored in a shared drive, hunt down all the documentation that you can. All the spreadsheets, the technical documents, the service catalogues, the lot. For each component, try and understand what it would be from a generic level, what capability it would represent, and where it would fit in the wider whole.
Research Pattern/Reference Model
For each high level component/application that has been identified from the search repository step, try and find generic documentation and support from the wider web as appropriate. Specifically for me, this involved looking at whether any other architects had produced an ArchiMate model for the system, some kind of starting point.
Update Scratch Model
Now we get to Archi, or your EA application of choice. I have created several scratch work areas within Archi, generally one for each high level capability, or project, or related suite of applications, and within these I begin the task of modelling each component. From the research conducted I try and get the key components together, whether that’s the Application Component or System Software and Device. This step generally descends into a chaotic mess, but it starts to build up the relationships in the model.
Whilst building up the model, there will inevitably be a number of assumptions made, where documentation may be light or unclear, which can be reviewed later, but can be added to the model as educated guesses so long as they are labelled appropriately.
Once the model has been built up to reasonable level, the diagram can be refactored to make the architecture clearer, and then reviewed with colleagues to ensure it accurately reflects the current state. Any changes here get rolled back in and potentially kick off another flow through the process as more knowledge is gathered and more systems can be searched within the repository.
Hopefully this has been of value, as I’ve stated several times, I’m not certified in ArchiMate or TOGAF although I am aware of the ADM approach. I have found that this process has been working for me while I build my knowledge and attempt to deliver a pragmatic approach to architecture within my new organisation.