Tuesday, May 26, 2015

Capability Matrices: Functionality Replacement

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 replacement
    • Including who "owns" that option
This 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.

-------------------------
Setup

Rows - The content library / CMS / LMS currently in our environment
  • Again - 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.  

video

Thursday, May 21, 2015

Capability Matrixes: Where do I stash my files?

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/CMS
  • Anything that needed to be external facing to our audience and didn't require tracking went to our web site
  • Working files, base files, anything that needed sharing among the project team etc went to a shared drive

Now - 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)
  • SharePoint
  • External-facing web site CMS
  • A Knowledge Management system
  • A Project Management system with document-hosting capabilities (that is also currently being switched out)
  • and...at some point...a Digital Asset Management system
I 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 features
    • I am using wiki, blog and real-time collaboration
  • Section 3: Who has approvals over content
    • When 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.

video


Tuesday, May 19, 2015

Application Architecture: Capability Matrices

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 materials
  • Showing 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 on
1) 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.


Thursday, April 30, 2015

Phase C: A High Level Application View

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 using
The 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.

Tuesday, April 28, 2015

The Technology Reference Model

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 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

Business Architecture Sample - Student Registration classroom





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

Business Architecture - The Individual Process Level


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)
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.