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. Once I have my list together, I can start putting together  my stakeholder contact list, a RACI chart, and the super secret power/interest grid.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.

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.I'm going to start this at a high level. We're going to break these processes down even further - but it provides a start as to what we need to start mapping out.---------------------Level 1 - the super duper high level. Look familiar?Figure out what training is needed and/or do intake for "training" projects.Design trainingDevelop trainingDeliver trainingFigure 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 SubjectObjectivesAudience Design trainingProject Management processInstructional Design process Outline developmentDelivery format DeliverablesDesign ApprovalsDevelop materials for trainingDevelopment process - first draft ClassroomWebinarAsynchronousBlendedCurriculum / Curation - or, how this stuff goes together if it is a multi-item project Iteration processPilots - you are piloting your training materials, aren't you?Modifications - pre-deliveryApproval for delivery / go-live  Deliver trainingRegistration process - for studentsRegistration management process - for trainers / stakeholdersReservation process - includes human resources, classroom resources, technical resourcesFor classroom, webinar, and any blended approach that uses synchronous trainingUpload process - where can we put this stuff so people can find it?For asynchronous and any blended approach using asynchronous trainingAlso consider any recordings resulting from webinarsALL 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 analysisUpdate process - or, how are we going to handle changes?

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.So why the gap?Work-arounds because the process is too slow, too kludgy, too dependent upon anotherThe 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.This is why it is really important to talk to the people actually DOING the process.  Not just the managers.  Because often the managers are hearing what their staff wants them to hear. And/or they don't want to admit that parts of their process don't work.It's natural. --------------A lot of time and thought and heartache and soul-searching are usually involved in any process improvement process.The admission something is not workingFeelings of shame because something in your area is not working Wanting to prove competenceWanting 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 negotiationsThe big reason why I have seen process improvement projects stall is because no one accounts for the emotions involved. You are shaking up their comfort zone. Often FORCING change and doing so in ways that only benefit one group of stakeholders without considering the others. There's something that works in the "way they've always done it."If not practically (anymore), at least emotionally. Ignore that.....monsters.

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 toMake sure I am using a visualization that makes sense to everyoneReduces 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) Since I am in very early days, I still have templates and systems to develop around this effort.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"My solution - just getting it down first. I have a lot to learn about Archimate and will use this particular flowchart to start learning it.This link provides some best practices for documenting workflows with Archimate.

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 stageIt's messy.  A lot like life.---------------------------I wanted to show you my process for documenting workflows.Phase 1 - what it looks like on paperPersonally - 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 itSo 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.....

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.Goldmine!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 graphicsSince 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.

From the Technology Reference Model,  the Integration SWAT Team guy then began to drill down into the architecture."I've been working mostly in the Applications, Data and Technology Architectures.  I haven't touched the Business Architectures."  He smiled.  I think he's leaving that for me.--------------------------I wanted to give you an example of what this looks like from our perspective.Below is an Archimate version (as best as I was able to put together) of a typical basic setup for a training group.  This is a high level Application and Data view.  I used Archi to put this together.The top level is your high level application service - ie: what you need your tools to provide.The second level is the actual functions that the tools deliver.The third level are the actual tools and applications you are usingThe fourth level is the data the tools are producing or accessing.From here, you start putting together how these things are related.(Warning, still learning, so you may see an edit to this after I talk to our Archimate guru)The solid line with the dots = "assigned to". If you look at the Online tutorials and LMS link, that would read "LMS is assigned to online tutorials"  I added "Trackable tutorials" since we are only putting tutorials that require reporting into our LMS.The dashed arrow pointing to something = "realizes".  Look at the dashed arrow between LMS and Content Delivery. This reads "LMS realizes content delivery".  Or, in more human language, I (the user) can find content in the LMS.The dotted arrow pointing to something = "access".This doesn't seem quite right and will likely need some review, but it means "LMS accesses LMS reporting".  Which is true in a sense since to allow a user to go back to a bookmark in a tutorial, the LMS will look at the records in its database to determine where that person is.--------------The nice thing about this view is that it begins to relate what you are actually doing to the tools you are using.More importantly, it provides us a way to start speaking the language of the folks who need to help us.---------------A more detailed introduction to Archimate can be found in the Open Group ArchiMate page.Again, this is just my attempts to apply it.  "Learning out loud."Any recommendations for improvement are highly welcomes.

Over the past year - I've been finding myself using Capability Matrices for a wide array of purposes:Evaluating whether to use one application over another when hosting training materialsShowing my management the level of effort (and money) it would take to replace key functionality if they choose to eliminate or replace a particular application.Figuring out WHY I don't like any of the tools at my disposal to accomplish a particular task A Capability Matrix generally has the name of the application on one axis and the requirements on the other axis.Below is a very high level SharePoint example from CMSWire.In this case, the requirements are the rows and the applications are the columns.-----------------------------------In an ideal world - the requirements would be pulled from the requirements that were used to purchase the application.I don't live in that world.Also - requirements lists can get pretty long. For our Unified Communications project - our requirements document was about 200 pages. When we finally get around to building out the capability matrix for that system, you can bet we are chunking that up into much smaller functional sections.-----------------I find the "requirements" in my early capability matrices have been based on1) The decisions that need to be made around the particular applications (keep or ditch? should I use this or that?)2) Generic requirements around that particular application - just go to any "checklist for evaluating X" article to find decent starter requirements.3) Surfaced use cases for our more mature applications (ie - what people are actually using vs the "nice to have")Over the next few posts - I'll talk through the use cases.

The first example I want to flesh out is the capability matrix I am using for determining where to host my training materials.Doesn't your organization have a content strategy?Thankfully, we are starting these discussions again - since the applications we are using for hosting have changed and multiplied.2 years ago - it was pretty straightforward. Any training content that needed tracking went into the LMS/CMSAnything that needed to be external facing to our audience and didn't require tracking went to our web siteWorking files, base files, anything that needed sharing among the project team etc went to a shared driveNow - we have:The LMS (for stuff that needs tracking)The web site (internal - mostly a server we upload files to)Google Apps (currently replacing our shared drive) A document management system (secure)SharePointExternal-facing web site CMSA Knowledge Management systemA Project Management system with document-hosting capabilities (that is also currently being switched out)and...at some point...a Digital Asset Management systemI still have projects where I need to have my materials tracked (occasionally) and visible (often).Plus - I still need to be able to find my own stuff.So in this example - I am using the capability matrix to help make decisions regarding where to host content.--------------Rough setup:Rows: each of the applications I have access to where I can store content.At some point, I will flesh this out to other applications that are in the environment.  Right now, I am more concerned about what I can do TODAY. Columns: The "requirements"Section 1: What file types each application can handle.eLearning has some file types and packaging that are not used by the rest of the organization.  I have also discovered the hard way that some applications handle these packages a LOT more gracefully than others.Some applications also handle certain file types "awkwardly" (please see Google Apps and MS Office)Section 2: Other desireable featuresI am using wiki, blog and real-time collaborationSection 3: Who has approvals over contentWhen I make a decision over where I want to host my stuff - the less approval overhead the better.  If I need to go through layers of approval - I always warn the project team that they will need to tack weeks onto a project and to not expect that materials will be updated quickly.  Since many of the projects I have been on recently have been Agile (though I haven't been on an implementation project in my entire career that hasn't had development occurring in parallel with training) - approval processes get very unwieldy very quickly.  Below is a brief demo video below of my current capability matrix for content hosting.

The second way I have used a capability matrix is to make decisions regarding application replacement.In this instance, management was investigating getting rid of our staff LMS.By itself, I don't have a problem with that.However, they were looking to do it in a very tight timeframe - as in, not renewing the contract that expires in less than a year.I used this particular capability matrix to show the following:What we have and what each application does (most of them are content libraries containing pre-built tutorials) What functionality we currently lose if we just stopped using that application.Our current options (ie - what we have in-house that doesn't require us to purchase anything) for replacementIncluding who "owns" that optionThis matrix quickly showed management the amount of work that would be required to make the transition.Our current Compliance program is very dependent upon our LMS.We can later use this same matrix to help guide purchasing future content libraries and LMSs.----------------------So Wendy, why did you put the content libraries and the LMS together?  They are different things!Not to management.  They just see "learning".Showing these things together helps show them the difference between the types of systems. -------------------------SetupRows - The content library / CMS / LMS currently in our environmentAgain - this is the stuff we are absolutely certain about.  There are many other LMSs and content libraries in our environment through individual schools and departments.  These change frequently and I'm currently not in a position to do an inventory.  Remember, I am doing most of this in addition to my current job.  And we are starting to hit the busy season for higher ed IT.Columns - Requirements For this one, I pulled the requirements we used for the LMS portion of the Talent Management source selection.  I then took them to a higher-level since management doesn't need to see the technical details.I also added some newer requirements - for when we decide to actually replace the LMS functionality.  Especially since there are new standards in our world (xAPI and CMI-5) that we will need to accommodate in the next iteration of our ecosystem.Finally - since our solutions tend to have content attached to them, I wanted to outline what content was in the libraries.