I ran into our SWAT team guy for integration after a meeting one day. He came from an organization with a more mature enterprise architecture practice. He also happens to be our resident expert in Archimate. I was hoping to pick his brain and see whether what I was doing a) was on the right track and b) would help him and the rest of the SWAT team in any way.
"I have something to show you."
We wandered back to his cubicle. He shook his mouse a bit and unlocked his screen saver.
"I found a really nifty tool called Archi. I've been using this to document our enterprise."
He opened up our Technology Reference Model (TRM). He and the other architects built it a while back and the SWAT Team Lead introduced a draft to us during the TOGAF certification training.
The Technical Reference Model (TRM) in TOGAF serves as the high level model and taxonomy for the architecture. Basically a high level model of what we have, where it fits, and what we are going to call it.
Your IT department should have something like this lying around their shop. Or at least in their heads. Our draft was based on IT's service catalog.
And there are many ways to visualize this model.
Ohio State provides a nice one.
Idea2Prod also provides excellent examples of a TRM + other diagrams and graphics
Since I am working in a segment (and a business segment at that), I wasn't worried about creating an entire Technical Reference Model. That rightly belongs in your IT department. I am, however, worried about particular sections of that model. The sections in red.
Behind each of those little boxes is a lot more detail.
Except for Learning Management and Training under Enterprise Applications.
The SWAT team left that for me.
Tuesday, April 21, 2015
The article this image came from talks about how the client-side marketing research department could politically position themselves to make use of the data.
A fascinating read itself - if not related to the below post...
As you might have guessed, I'm writing these posts as I am doing the work.
And you may have noticed that I am not doing the stages "in order".
I'm organizing and creating the pieces as the opportunity and inspiration presents itself.
Such is the risk when a venture like this is done as a "side job".
All of this information eventually appears in the following stages:
- Preliminary (to see what we have) - referenced in the Architecture Definition Document. Eventually.
- A: Architecture Vision (to help us developone)
- and the appropriate Architecture development stage
It's messy. A lot like life.
I wanted to show you my process for documenting workflows.
Phase 1 - what it looks like on paper
Personally - I find it a lot easier to hash workflows analog.
There are many ways to do this. I know sticky notes are really popular.
But I tend to come up with these ideas in random environments.
I don't have an "assigned" office where I work.
And I fear losing sticky notes.
Phase 2 - getting it on computer in a way I understand it
So this is the first draft. I left out specifics for my organization, but I figure this is a general workflow for a lot of us.
A few things I am trying to do here.
- First pass at an attempt at Archimate. As in....first time EVER.... I warned you that you are seeing this as I do it.
- Get it in electronic format.
- Refine it. I think differently on paper than I do on computer. I catch things I may have missed.
This was done in Visio. But you can also do this in PowerPoint or Word if you have access to those.
Since this is my first process flowchart for this Learning Ecosystem in this new format, I am also using this as an opportunity to build out my templates.
Next steps for me....
- Show this to my colleagues on the team. Is this right? Does this make sense if I wasn't around to explain it?
- Once I have the workflow right....talk to our SWAT team - does this make sense to them? Could they work with it? Remember - this whole initiative is about being able to communicate to both the business side (ie - the trainers) and the IT side (which is being represented by the SWAT team)
- Talk to our resident Archimate expert. To see how badly I bungied this and what I need to do to modify and other considerations.
There are lots and lots of these to build. Not just for the individual workflows but also for how they relate to each other.
Think I need to build out a production list.....
Thursday, April 16, 2015
Now that I have a rough idea of what processes I need to document, it's time for me to start mapping out the individual process. The act of doing this will help me break this down further.
Working within a training team, I figured it was best to start with us.
This will also help provide a point of discussion when I talk to other teams.
Allow me to see how our process differs from theirs and why.
We have already defined the general processes we need to begin mapping.
The first process I am documenting is our Registration process for students.
Eventually, I will do all of the processes, but I wanted to start with something that was pretty well-defined and possessed common agreement among all of the participants of this process (ie our team).
Choosing something "easy" allows me to
- Make sure I am using a visualization that makes sense to everyone
- Reduces the risk of me setting off alarms around what I am doing (remember - "Planning" can be perceived as threatening. Here Be Monsters.)
- Shows progress quickly to others.
- Gives me a quick "discussion point" for the other stakeholders.
- Gets me comfortable with the process of building and validating these flowcharts.
- Provides more bandwidth to experiment with the architecture program itself vs arguing over the accuracy of the individual flowchart (at least....that's the hope)
I've got a mess of processes to document.
- Have I figured out a process to develop these flowcharts quickly and accurately so I can focus on the accuracy of the information vs. playing with Visio / PowerPoint / Archimate / other flowcharting tool?
- Do other people understand what I am trying to communicate? Stakeholders? Executives?
- Does this fit in with the Architecture team's standards? (Remember, this is going to help them too...)
- Is this easy to edit and share once I am done with it?
- How many other people do I want to give edit permissions to these workflows to?
- How I am going to organize this information? Can other people find it?
So before documenting - I asked the Architecture team the following questions:
- Is there a particular tool you want me to use?
- Their answer - no.
- I'm using Visio for this effort, but you can also use PowerPoint, Word, or drawing stuff out on paper and taking a picture with your cell phone.
- Actually...drawing stuff out on paper or using sticky notes and a wall isn't a bad way to start.
- Is there a particular modeling technique you want this in?
- Their answer - "Well, Archimate would be nice"
This link provides some best practices for documenting workflows with Archimate.
Tuesday, April 14, 2015
This is the Carta Marina. Please note the monsters.You will find some on your journey.
An interesting interactive version of this map can be found at Slate.com
I now have a rough idea of the processes that need to be documented.
And this is where things can get a little hairy....
I've learned that anytime you document human processes you learn:
- What is "supposed" to happen (often "management's" perspective of the situation)
- What actually happens (usually discovered when you are talking to the people who actually do the work)
- The interesting behavior that occurs among your stakeholders when you uncover the difference between the two.
- Work-arounds because the process is too slow, too kludgy, too dependent upon another
- The tools that the process relied upon didn't work quite right when they implemented the process and they never bothered to retrain after the initial implementation.....
- The designed process doesn't create the designed result, but no one will tell the process designer (often an executive-type) - so this is the cover-up
- "But we've always done it this way" (cites process they learned when they joined the company 20 years ago)
- Someone is leveraging the process for his/her personal ends .... Thankfully, this is infrequent.
A lot of time and thought and heartache and soul-searching are usually involved in any process improvement process.
- The admission something is not working
- Feelings of shame because something in your area is not working
- Wanting to prove competence
- Wanting to improve a situation for themselves, while negotiating around others who want the same thing, just maybe in a different way. And the emotional stress of those negotiations
There's something that works in the "way they've always done it."
If not practically (anymore), at least emotionally.
Thursday, April 09, 2015
Argue about the validity of ADDIE if you must, but most training teams I have encountered still use this as an organizing structure for what they do.
I'd rather talk to my stakeholders in a way they understand.
This particular iteration is from Chico State IDTS.
The "Power Users" for the Learning Ecosystem will be the folks performing staff training design, development and delivery activities.
One of the important things to figure out is what these folks actually do.
This is the start of the investigation for the Business Architecture.
In my organization - there does not seem to be any separation between the design/development team and the delivery team in the groups that do training. Often, its the same person from start-to-finish. And EVERYONE (stakeholders and trainers) is curious to see whether the training "worked" (or at least got some butts in seats).
Where I found the differences between the groups in my organization was in each team's preferred delivery format.
- Some groups are really "classroom heavy".
- Some groups did a lot of webinars.
- The group I am in tends to do a lot more asynchronous development and assists other teams with their asynchronous development.
Level 1 - the super duper high level. Look familiar?
- Figure out what training is needed and/or do intake for "training" projects.
- Design training
- Develop training
- Deliver training
- Figure out whether training worked
Level 2 - High-level processes that all of the training teams seem to do. There might be some things that a particular team doesn't do - but I want to make sure every possibility is covered. This is going to help give us a rough outline of the scope we are dealing with for the Business Architecture.
I reserve the right to change things as I discover stuff and think things through. Consider this an "agile" document.
- Figure out what training is needed and/or do intake for "training" projects.
- Project intake process
- Needs assessment process
- Design training
- Project Management process
- Instructional Design process
- Outline development
- Delivery format
- Design Approvals
- Develop materials for training
- Development process - first draft
- Curriculum / Curation - or, how this stuff goes together if it is a multi-item project
- Iteration process
- Pilots - you are piloting your training materials, aren't you?
- Modifications - pre-delivery
- Approval for delivery / go-live
- Deliver training
- Registration process - for students
- Registration management process - for trainers / stakeholders
- Reservation process - includes human resources, classroom resources, technical resources
- For classroom, webinar, and any blended approach that uses synchronous training
- Upload process - where can we put this stuff so people can find it?
- For asynchronous and any blended approach using asynchronous training
- Also consider any recordings resulting from webinars
- ALL supplemental information from the classroom and webinar approaches should be considered here as well.
- DevOps - or, how are we going to maintain this stuff?
- Communications process - how do we tell people that this is available?
- Reporting process - I'm sticking this here because it makes sense to me right now. In operations, people tend to run reports right after training delivery. Butts in seats and if they are happy - mostly. I may change my mind later.....
- Figure out whether or not the training worked.
- Evaluation process / Report analysis
- Update process - or, how are we going to handle changes?
Tuesday, April 07, 2015
An important step in this process is to figure out who your stakeholders are and perform a bit of Stakeholder analysis.
- What is their role in this architecture?
- Responsible for completing an action in the architecture?
- Accountable for making sure that action is completed?
- Consulted (advised) if something needs to happen?
- Informed once certain things are finished?
- How supportive are they of what you are trying to do? (Interest)
- How badly can they derail your plans? (Power)
These are the questions I asked during the first go-around when I was trying to figure out who did staff training at the University.
It's been a few years, so I need to get back to my network and start asking questions again. This will be happening mostly on an "opportunistic" basis.
- Do you train people? - Looking for other "trainers". Just because they don't have "trainer" in their title or don't have "training / learning / education / etc" in the organization name doesn't mean they don't perform training activities.)
- Do you NEED to train people? - Looking for SMEs + people who need to get reporting out of this architecture.
- Are you responsible for a compliance / regulatory program?
- Are you responsible for an IT application?
- Are you responsible for a mission-critical business process?
- Do you have to maintain a certification? - I'm asking this more to isolate "power-users" since pretty much everyone in the organization has to touch this system as a "student". Particularly for the certification programs.
- Do you find learning new things "interesting"? - I'm also looking out for people who are excited about making the experience for the end user better. These people usually give fantastic feedback and will take the time to do so when the other groups might not.
- Who ELSE do I need to talk to? - This is the "political" question. The answer to this question will also tend to be the people who magically "appear" when you are about to actually do something and can derail a plan quickly. Best to get these folks involved early.
All of this stuff gets dumped into my Architecture Repository as I do the information gathering.
Because this is a large scale, long-term effort - I anticipate the stakeholder list, the RACI chart and the Power/Interest grid to change as things evolve. I will need to come up with processes to keep things up-to-date.
Thursday, April 02, 2015
From lynda-m at Deviantart.com
The Preliminary Phase of the architecture is supposed to have 4 outputs. I am outlining these below to help provide a checklist of the types of information I need to gather and some of the early decisions that need to be considered.
- The Organizational Model for the Architecture provides a rough idea of what you have to work with:
- Who is impacted
- Who we need to target for governance and decision-making around the architecture
- What roles these people play - I'm going to include support here
- What we have
- What we don't have
- Constraints around what we can do to fill the gaps
- How much money we might need (though I am going into this assuming there will be NO money)
- Usually - there would also be an assessment of architectural maturity. The answer for us is "non-existent and the gap is huge and I may have potentially bitten off more than I can chew, but it's worth a shot....."
- There is also a Tailored Architecture Framework. In this will be:
- What method I am using (deciding to use TOGAF. There's other methods)
- What other methods for activities need to be used to align with the organization (I'm sure more will appear as I work on this)
- Service Management - ITIL
- Project Management - PMBOK
- Requirements Management - tbd. Could be BABOK or Volare or something else
- Templates for deliverables
- Architecture principles
- The Initial Repository (where I'm storing stuff)
- Other tools I should be using.
- Flowcharts - Visio, planning to use Archimate modeling
- MS Office
- Anything else that may come up that will help me communicate to others
There would also be a Request for Architecture Work created by a sponsor. This document would contain high-level information on the following:
- Mission statement for the architecture
- Business goals to be addressed by the architecture
- Strategic plans for the business
- Time limits
- Changes and challenges in the business environment triggering this architecture
- Constraints - internal and external
- Budget constraints and information
- Current business system description
- Current IT system architecture description
- Description of the developing organization and the resources available
The Architecture Definition Document defines what this architecture / ecosystem IS.
This will be written after the other three documents are at least in draft form.
- Scope of the architecture - in my case, "Learning / Teaching activities"
- Goals, objectives and constraints for the architecture. This would be defined in the Request for Architecture work.
- Architecture principles - how I'm basing decisions for the Target (future-state) architecture
- Baseline architecture
- The architecture models, for each iteration of the future state
- The rationale and justification for the approach -why I'm using TOGAF instead of Zachman or some other architecture model
- The mapping of the Architecture Repository - where it is, table of contents, how to categorize stuff, how to find stuff
- Gap analysis - what needs to happen to go from point A to point B
- Impact assessment - what we think will happen if we manage to be successful
None of these documents will be final at this point.
I personally see it as more of a checklist....
- Do I have everything I need to answer these questions?
- Have I thought of everything that may apply to the architecture?
- Is the definition of my scope accurate and clearly delineated?