From Techfellows – University of Alaska Anchorage.
—————————
As I put together the architecture, I have to decide whether my efforts are going to be present-focused (ie. capturing the current baseline) or future-focused (ie. documenting where I want to be – also known as Target First).
Unless you work for an organization that has clear, centralized configuration management and everyone (you, your IT group, the stakeholders) has a solid understanding of the current architecture, chances are you will be documenting Baseline first.
This is a really good exercise. I personally find it hard to do any system improvement if I don’t know what the system is in the first place. Not that I haven’t tried….
———————–
There are three main “architectures” I will be documenting during the course of this process.
- The Business Architecture (Stage B) – ie What people do. Focused on what they REALLY do vs. what we THINK they SHOULD be doing. Warning: Danger lurks here.
- The Application Architecture (Stage C) – ie What tools we use.
- The Data Architecture (also Stage C) – ie What we are trying to get out of it and where that information is housed.
So what about the Technology Architecture (Stage D) you ask?
Chances are, your team (talking to mostly trainers and educators etc) is not responsible for the infrastructure of your tools (servers, the network, whether or not it is in “the cloud”etc).
This will be a good opportunity to make friends with your IT folks who have knowledge of these things. We’ll talk about the questions to ask later….
————————–
As you’ll notice throughout this series, I am doing a number of these phases in parallel vs. in the correct “order”. Again – taking advantage of opportunities as they present themselves.
Besides, there is nothing in the TOGAF manual that says I HAVE to do things in order.
And anyway, so much of this process for me is a “fact-finding” mission to see what we have and what we are working with.
My goals for this process are:
- Figure out what is lying around
- Determine how to optimize what is lying around
- Identify gaps in functionality (and, ideally, avoid duplication)
- Identify knowledge gaps and fill them
- Identify stakeholder gaps – now is a good time to do the “people work” to minimize political surprises later.
- Share what I’ve learned with the organization.
- Put TOGAF through its paces to see what works.
None of us have really done this before. And the best way I learn something is by doing it. And if I have something concrete – I can see what modifications need to be made.