5 top tips for organizing your architecture repository
Jan 5, 2017
Software platforms such as Enterprise Studio are powerful tools that can support transformation activities if used in the right way. Otherwise there is a risk it becomes shelf-ware. As the saying goes: “With great power comes great responsibility” – this rule applies to the architecture repository as well, and with this, a few tips for getting organized.
As above, power and responsibility come hand in hand. Often there is a reluctance to be proactive and have nominated person(s) take charge of maintaining and updating repository assets. This is essential to make it a success, and no, it doesn’t mean that people must ‘give up their day job’ to do this. With a little bit of time and effort – standardized processes help, you’re on to a winner.
When we talk about repository structure – the heavyweight users tend to be architects and analysts – who need to find, update, reuse frequently. Always keep their working methods in mind, and organize accordingly. When in doubt, a little conversation can do wonders, though compromises do sometimes have to be made. Pointing back to the previous tip, as a collaborative business design platform, why not put responsibility on groups of users?
At BiZZdesign, we leverage open standards such as TOGAF, ArchiMate, BPMN, DMN etc. which can serve as a good starting point, with plenty of reference content out there to look at. One of my favorite ways to structure is based around the TOGAF ADM phases, i.e. Preliminary, A. Vision, B. Business Architecture, C. Information Systems Architecture, D. Technology Architecture… which by default gives a simple, yet very useable way to find domain specific information quickly.
Previously I wrote about leveraging existing data from other sources, which mentioned the process of bringing information in to Enterprise Studio. Often organizations have a structure in mind, others just want to bring the information in, and think about re-shuffling afterwards. Luckily both are options – very rarely do people perfect it up front. If later on down the line, the structure doesn’t work, it’s very simple to update, and just drag-and-drop to move things around.
This sometimes goes against principles, but when starting out, just getting going and making a start is the best piece of advice (and again, being flexible means this isn’t such a bad thing). ‘Current state’ changes almost immediately, so the faster the repository is being populated, the faster the ability to adapt to change.
Good luck with architecture repository!
