This blog of mine has been kicking around, sitting unused since 2014 when I finished the MBA. After a year of learning about what Enterprise Architecture is, and sharing a few other Enterprise Architecture (EA for short) posts, I finally have a purpose for this blog, and it is to tell (and keep track) of my journey into this not-so-new but interesting practice. The area itself is not relevant to what I do on my day-to-day IT Analyst job, but it has been a huge influence in getting better at it.
There’s a lot more to EA than Archimate, and I hope to explore and share a lot of it via this blog. The notation language gave me a lot of insight into thinking in terms of Architecture, and in terms of Enterprise. There’s also been a lot of thinking on opportunities for capturing current state and how to deal with unstructured data. I hope to finally use this blog to explore my adventure into the world of Enterprise Architecture, Architecture Artifacts, frameworks, ontologies, knowledge graphs, etc.
Back in October of 2017, I was growing a bit frustrated with the way we were doing architecture diagrams within our wiki site. Although I had some successes in representing system architecture with the build-in graphic tool, it was frustrating not be able to reuse/recycle the elements in these diagrams, the lack of depth in them (no metadata or click thru), and the biggest challenge of all, which is the same with all knowledge-base efforts, maintain them current.
By then I was working with a hand full of application admins on about a dozen applications, with a few more coming down to my plate. With so many apps, and the diversity of their environments, we had a huge need for documenting their architecture as much as possible. With the advent of the Windows 2008r2 EOL, this provided a good opportunity to revisit each application’s architecture in detail.
With architecture diagrams, depending on the perspective and needs, I would normally draw a few diagrams per app: infrastructure (network and servers), applications components and integrations, data structures and ETL processes (if any). I say basic diagrams as each had no more than a dozen or so objects in them. If I’m to revisit twelve Applications, I was going to end up easily drawing (and maintain) thousands of graphical objects. No way I’m doing that manually. No way I’ll be able to maintain them up-to-date. I need a better way of doing diagrams.
I don’t feel particularly happy about setting up a proprietary stack to maintain documentation, much less one built on Microsoft (which is my background). I once set up a Sharepoint and a SCCM server while I was studying for the MCSE. There’s potential in the idea, but Visio would be a solution with a lot of technical compromises.
Either way, the diagramming tool is only half the question, the other half is the visual language. Tweaking visual objects so they could convey more context to the reader is daunting. If you want to represent a device, a network, a process, or an individual, diagramming was becoming purely an exercise in creativity, rather than a communication tool. There’s an iconography with Cisco and once you learn their meaning, these diagrams become natural part of the learning process. To this day they even have official stencils for Visio.
Now there’s plenty of iconography already available on the internet to represent every aspect of IT architecture, but that was part of the problem, I would have to write a legend in each diagram or a guide on how to read boxes, circles, and lines. There’s just so much and basically having to start all over again when there was a need for a new diagram or point of view, its all just too much. It was then that chatting with my next door office mate he pointed me to look into this app called Archi and ‘Archimate’.
At first I didn’t understand what Archimate was all about, it looks like a boiled down UML, something I once tried but got lost in, also instead of being an universal notation, is specific to architecture, Enterprise Architecture(?). I was intrigued.
For the next few months I tried to understand Archimate, and the whole concept behind what EA is all about. In my years in IT experience I did not know this practice was actually formalized and adopted by the ISO. I had been so focused on service management frameworks like ITIL and Microsoft Operating Framework, that I completely missed the boat on EA. I had heard of Zachmann’s architecture framework, but I thought it was no more than an academic exercise. Boy was I so wrong!
After a couple of months setting up a test environment, I customized some reports from my asset management system to conform with the CSV import. The file is exported and I’m able to tweak it. I see on the XML file that elements get created and assigned a Universal Unique Identifier (UUID), so a couple of tweaks to the inventory database, a few tweaks on the reports logic, and now I have a central repository for my Archimate elements. One server in my Asset Management ==> One Archimate Node… or should it be an Archimate Device? Well, either way… this works. By March 2018 I had my first ‘Archimate Model’ and had published a new Wiki article with an embedded image of my diagrams. Time to submit a request for a real server and get an Archimate book.