In TOGAF (The Open Group Architecture Forum) terms – this is the Architectural Development Model (ADM). Because acronyms are awesome.
Please go to Introduction to the ADM and scroll down to section 5.2.2 for the official explanation and definitions.
These are mine (with apologies to the Open Group)
Preliminary – “What do I have lying around?” Our organization is here.
Requirements – “What do people want this thing to do”. Lots and lots of levels to this. I’m in the process of gathering 7 years worth of stories and figuring out how to build a requirements library.
A – Architecture Vision – “What is the high-level architecture and, roughly, how do we want this to evolve?” Don’t worry – the next few phases will nail this down.
B – Business Architecture – Nailing down processes and workflows. What people actually do. “How do we want to improve the process?” Note: This piece SHOULD guide the other architectures. However, B, C and D are often developed in parallel in practice.
C – Information Systems Architecture – This is all of the tools that you use to perform your processes.
The model breaks it down even further into Application architecture and Data Architecture.
- Application architecture focuses on what tools you use.
- The Data architecture focuses on what information goes in and out of the applications and where it goes. Don’t neglect the Data architecture. We will need this for reporting later. You are doing reporting, aren’t you?
D – Technology Architecture – This is the servers and network etc. Making friends with your IT department will be key. You know…in case they move a server your LMS is housed into the cloud. Because there are other, non-technological ramifications to this action. Like having your user interfaces change on you without warning. Or if they are having a maintenance outage that suddenly prohibits access to your webinar tool on the day you are presenting to 100 people. So it is good to have at least a rough idea of the technology architecture of your applications.
E – Opportunities and Solutions – This is where we nail down where we want to go. What we want our future state to look like.
F – Migration Planning – This is where we plan how we are going to get there. Which projects, what order, who we need to help us, that sort of thing.
G – Implementation Governance – “Git’r Done”. Making real.
H – Architecture Change Management – Did we actually get there? What worked? What didn’t? What needs to change in the architecture plan? Where do we want to go next? For those of us versed in ADDIE – this is the “Evaluation” piece.
As we were warned in our certification training – the first go-around through the cycle is the toughest. Because all of the stuff is spread out and disorganized and housed in people’s heads.
Our organization is using the Learning Ecosystem as a smaller scale way to start hashing through this cycle. Mostly because I am motivated to actually use this thing I learned – at least for my own needs, even if few other people find it useful. And I think it is “low profile” enough to allow the SWAT team and I to experiment with some things around how this might operate on a larger scale.