Category Archives: Work

Writings on being an Enterprise Architect / I.T. Architect in academia.

Architecture and finding the path

Ron Kraemer, our VP of Information Technology and CIO, spoke at the IT Leaders Program this week. He built on his blog post, Interdependence – Both Positive and Negative. To paraphrase:

The growing interdependence of our systems is driving the complexity of our systems towards the edge of chaotic systems. The choices that we make are no longer focused on finding the perfect solution. Instead, we can see many possible solutions, many of which are good solutions. The choice is then to pick the solution which builds positive interdependency and limits negative interdependency.

Interdependency and Complexity

Fig. 1: Growing interdependency has put us at the edge of complex and chaotic systems.

In his talk at ITLP, Ron also pressed on the ever-growing rate of change. These two factors limit our ability to design and implement perfect solutions to problems. To paraphrase again:

If you take two years to design a great solution, the landscape will have changed so much that the solution may not be applicable. The level of complexity makes finding and defining the perfect solution even more difficult. The level of interdependence means that even more good solutions are available – when many systems are connected, many systems could be used to provide the solution.

Impossible Route to a Perfect Solution

Fig. 2: Impossible Route to a Perfect Solution

I agree with what Ron has come to believe. The level of integration between systems is very high. The expectation for real-time interactions has become the norm. Users expect to see real-time flight information. They expect real-time updates on openings in courses. Students can see, in real-time, the bus schedule, where they are located and the location of nearest bus stop and the location of the buses on their routes.

This interdependence has driven complexity to the point where perfect solutions are hard if not impossibly to design and deploy. Therefore, we must choose from many good solutions that exist. We need to act quickly to implement some solution to meet the rapid rate of change.

Many good solutions

Fig. 3: Many good solutions

This is where Enterprise Architecture and the other architecture practices can help. If we look out to the future and think about the desired state, then we can begin to sift out those good solutions which move us towards that future state. For us, we had stated that Service Oriented Architecture was a strategic direction. That bounded the future state some. In the student area, we had a future state process diagram. This diagram outlined improvements to the way that students manage course data and move through finding courses to enrollment. This put another boundary on the future state. When it came to think about how we get course roster type information out to a new learning management system (Moodle), we were able to use that projected future state to pick from the possible solutions (flat file transfer, shared database connections, web services) those which moved us closer to future state.

Architecture filtering the good choices

Fig. 4: EA can help filter the good choices that move you towards the desired future state.

The rate of change and interdependency drives the importance of an architectural approach. If you have not thought about the future state, then there is a multitude of choices. To pick from many choices, you have to establish some factors that affect your selection. In a restaurant, this might be dietary restrictions, cost, the weather outside. In technology, it is often quickest and cheapest. But those factors, in this complex environment are often shortsighted and misguided. The quickest and cheapest solution might need to be replicated many times for many systems. This would increase the interdependency in a negative way and push you even closer to a chaotic system. A more expensive, slower solution might serve you well over the long haul.

Architecture can help you make those choices in a framework that is focused on the future and on the overall complexity that you are creating. Enterprise Architecture (and the other architecture practices) can help sort those good solutions and help make sure the choice you make is along the path to desired future state.

SOA – Maturity is Key Presentation, EDUCAUSE Enteprise 2009

My presentation on SOA in the Enterprise – Maturity is Key has been posted in a couple of places.

First, on the EDUCAUSE site is the talk listing:

EDUCAUSE – Enterprise 2009 Site

Slides can be found at Slideshare.net:

Blue Sky to Ground part 1

 

 

Soaring

Soaring

I’ve been working with our CIO on the I.T. strategic planning initiative.  At the same time, I’ve been working with the Technical Directors and Operational Directors on planning at the technology level.  They have been creating a map of what technologies are used to support our services.  I’ve had my head in the blue sky of the strategic planning process while I’ve also had my hands in the dirt of the technology mapping.   I keep coming up against the issue of how to connect the blue-sky of the strategic plan with the down-in-the-dirt technology planning.

Finding a process and methodology to connect the sky to the ground has taken up a lot of my mental cycles recently.   The following is my take on a method to connect the strategic planning to the technology planning. 

1.  Strategy to Capabilities

The first step is to take the general directives of a strategic plan and have them expressed in terms of capabilities.   I see this work being done by leadership as part of a collective planning exercise.   As an example, a strategic initiative might be: Classrooms and learning spaces will be equipped with a base set of instructional technologies.   This strategic direction then needs to be interpreted into a set of defined and measurable capabilities.    A leadership team would be charged with determining the capabilities that would meet this strategic direction.  The capabilities should be measurable.

For example, the capabilities might be:  Multimedia Projection, Student Response Measurement and Lecture Capture

We could survey all rooms and learning spaces and get measures of current state (for example: 65% of rooms meet the projector capability, 15% meet the student response and 10% meet the lecture capture capability).   We could then decide priority – which is more important lecture capture or student response – act on those priorities and measure improvement.

2. Capabilities to Services

The next part of this to map our services to the strategic capabilities.  Some services support multiple capabilities (Hosting Services, Identity Management Services for example).  Some capabilities may not have a supporting enterprise service.  A capability that does not have a set of supporting services might indicate a gap in the enterprise.  For example, there may not be a matching Lecture Capture Service that provides the Lecture Capture capability.  This might be done in an ad hoc fashion or it might be missing completely.  This gap in the enterprise service would be worth evaluating to see if the capability is being delivered effectively in the current structure.  If not, then we might want to look at developing an enterprise-wide Lecture Capture Service that supports all of the classrooms.  

3.  Services To Technical Roadmaps

This is where we use the brick diagram in our planning.  The brick diagram captures the technologies that support a given service.  The brick captures what is current state (those technologies currently in use), what is tactical (what will be used for the next 0-2 years), what is strategic (on the plans to use 2-5 years out), what is in containment (no new development), what is in retirement (being stopped) and what is emerging (interesting trends that may move into the tactical or strategic realms in the future).  

These brick diagrams are created and maintained by the service owner – that is the group that manages the service being provided.  The bricks let the service owners and the service teams grab a snapshot of their current state and their strategic plan for the next few years – what they will leverage, what they will stop, what they are watching and what they want to move to – in a simple format.

 

Core Planning Stack from Tech to Strategy

Core Planning Stack from Tech to Strategy

This set of relationships is managed by a set of governance process that define and prioritize the layer below.  

At the lowest level, the service manager or service team usually defines and prioritizes the technology they use to deliver that service.   This is the layer that is captured in a brick diagram.  They should also describe the capabilities that are delivered by their service and which strategic directions they support.  

At the top level, senior leadership should work to refine the strategic directions as measurable capabilities that want to see delivered.  

The mid-level governance is a gap in our institution.  It is probably filled by project prioritization processes and budget processes.  I’ll talk about that in part 2 of this post.

Uncommon Thinking…

From the Flickr stream of Bre_Pettis

From the Flickr stream of Bre_Pettis

 

I was chatting with a colleague about the new EDUCAUSE slogan, “Uncommon Thinking for the Common Good” when I realized that the saying encapsulates one way to think of my work as an I.T. Architect.  “Uncommon Thinking for the Common Good” is what I try to foster in the teams that I work with.  I’ll explain this in two parts “Uncommon Thinking” and “for the Common Good”.

Uncommon Thinking:

I try to break people out of their daily routine and their comfort zone.  For instance, I have sat in meetings where a team is supposed to develop a new user interface (UI) for a new application.  I’ve watched as team redraw the UI for the old application, that they use day-in and day-out, as the solution for the new system.  I’ve also seen teams “re-think” how a business process could be done.  The end result was an automated version of the current process.  The new implementation of the old solution substituted emails for people running around with paper.  They are following the same steps, replicating the same authorizations and sending the same forms often without asking “why this form” or “why this person” or even “is this necessary at all”.   My job is to get them to question their old ways of doing things.

People like what they know.  They understand what they use daily.  But advancement comes when we change and disrupt routines, not when we replicate them into a new technology.  You have a telephone book at home with White Pages for people and Yellow Pages for businesses.  Changing that into two Word files you can print doesn’t bring great advancement.  It might be easier to carry only the pages you need but that doesn’t really improve the process.  Search capabilities are a big improvement.  Rethinking how you use the information, such as mapping businesses onto maps so you can find restaurants near your hotel, that brings advancement.  The routine of grabbing a book and looking something up is thrown out.  The new routine is to grab a laptop, look for wireless and Search.

I often introduce myself to new teams saying that my job will make them uncomfortable because I will ask them to throw out what they know and what they are comfortable with.  I tell them I will challenge their assumptions.  I say this not because their assumptions are wrong but to make sure their assumptions are correct and we accept them for the right reasons.

I love the fact that the Web 2.0 explosion is going on.  There are so many examples of “other ways to do things”.  I bring these examples and ask, “why can’t we do this instead?”  I show them Netvibes and ask, “can we make our pages this flexible?”  I show them Etsy’s Find By Color page and ask, “can we make creative ways to search like this?”  I show them The Northface catalog and ask, “should we have filters to help people search like these?”

 

Etsy Color Browser

Etsy Color Browser

 

 

It’s not that I think we should have a UI that looks like any of these sites but I want to break the team’s mindset and get them to start thinking about all of the rich possibilities.  I want them to work with a blank canvas and a rich palette of colors.  I want them to really get imaginative in their solutions to the problems.

I had a watercolor instructor that I worked with at UC Santa Cruz.  We were painting in the woods one day.  Everything I produced came out flat, boring and uninteresting.  They were awful, actually.  I was having a terrible time.  He came by, had a look and asked how it was going.  I grunted out my disgust.  He said, “Give me three paintings, but you can’t use any browns or greens at all. No earth-tones.”  I’m sitting in a forrest of browns and greens.  I was forced to paint purple and blue trees and red ferns.  At first it was very uncomfortable and I was very hesitant.  The first attempts were also awful.  But then, it became fun and playful and the paintings improved.  I was forced to let go of “how it is” and instead I had to play with “how it could be”.

That is the uncommon thinking of the Architecture practice.  Letting go of the how it is and thinking about how it could be when we start with a blank canvas and rich palette.

For the Common Good:

The other aspect that I deal with on teams is the narrow focus of their solution.  Often, the solutions that are put forth solve the very local needs of the group of people sitting around the table.  My work is to ask, “how does this fit with the broader issues that the people deal with daily?”  “What does this solutions do to actually help people?”  “What impact will this have on them?”  Not all solutions should be broadened and generalized to solve a larger issue but we should consider their larger impact. 

Every application must fit into an already rich application environment.  No application is truly a silo-application anymore.  Someone has to use it.  That someone already has a username and password if not several.  That someone already has a day that is full of tasks and applications.  That someone has things that don’t work so well, things that they are comfortable with and things that they cherish dearly.

The impact assessment of a new solutions should consider all of those people that the solution will effect.  If the new process changes their lives from reading paper documents to reading email, the users might not consider it an improvement.  What if reading the paper documents is what they do on the train in the morning?  Then your solution is a step backwards for them.  What seemed like a good idea to the team, reduce paper and use electronic delivery, actually was negative impact to the user and to overall productivity.  The user did that work before they got to the office as part of their daily routine.

This is part one of the “For the Common Good” part of my job. The solution that is delivered needs to take into consideration all those that will be impacted and it needs to fit into their lives and, ideally, change their lives for the better.

The second part comes into play during information gathering and sharing about the solution.  The new application or solution needs to be described in terms of the business value and the overall positive value of the change.  If you are going to add work to busy departmental staff, then it better be for something more than “your system”.  It better be for something like improving the enrollment process for students.  It better be for some larger good than simply benefitting the group developing the solution. You need to gather the business process improvements that the new solution will provide and then use those improvements to describe why the solution is important.

The final part has to do with scope.  Often, issues in one group are problems in another group too. Finding co-sponsors is a way of expanding the positive gain for the new processes or solution.   I spend time looking for others who I can bring into the discussion.  I look to see if the problem can be solved once for several constituents.  The broader solution will require collaboration and compromise but it can bring greater value and reduce the chaos of one-off solutions.  If the problem is solved once for many groups, then there is only one solution to maintain and there are many people who can provide input and expertise.

For me, “for the common good” means considering the broad impact, looking for the greatest value and delivering a solution for the largest constituency.  

Uncommon Thinking for the Common Good:

Bringing this all together provides one view on what I do as an I.T. Architect.  I get people to think broadly about a solution.  I get them to use a blank canvas and a rich palette of ideas when thinking of how we should solve a problem.  I also get them to think about how that solution fits in the larger environment, who it will help and who it will impact and finally who else should be brought into the discussion so we can deliver a far-reaching solution.

If I do my job well, then we get truly creative and expansive solutions that fit into the organization, improve peoples lives and help the greatest number of users.

 

Technorati Tags: , , ,

ITANA.org – bringing the catch home

 

Image courtesy of the Nova Scotia Museum

Image courtesy of the Nova Scotia Museum

I’ve been pondering, wondering and worrying about how to bring value out of ITANA.org to the world at large.  I struck upon a metaphor over dinner with a friend at EDUCAUSE recently that brought my vision and the issues I’m pondering into sharp light for me at least.

 

I watched Captains Courageous, a wonderful 1937 film with Spencer Tracy, recently.  This is a story about a spoiled boy who ends up on a fishing Schooner.  The schooner would launch dories with fishermen aboard them.  The dories would bring there catch back to the schooner where the fish would be processed and packed.  The schooner would then bring the catch back to the mainland and to the public.

ITANA.org spins up sub-groups that work on a topic.  These are the dories if you will.  ITANA.org and its sponsors, EDUCAUSE and Internet2, act like the schooners and the delivery systems on the mainland. 

If I take this as the operating principle for ITANA.org, then a variety of questions pop into my head:

  • How do I make sure those sub-groups have the resources needed to bring back a meaningful deliverable? 
  • Who should be, as it were, on the dory doing the fishing? (It’s my metaphor and I’m sticking with it to the end – Jim) 
  • How do I make sure that the delivery from the sub-group to ITANA.org is a smooth as possible and as efficient as possible? 
  • How do I make sure that the sub-groups are working in fertile fishing grounds?
  • How do I make sure that what we are delivering is what the mainland wants?

These are the things that I’m wrestling with as I get ITANA.org up and running.

I see a lot of interest and potential in the bright minds that participate in ITANA.org.  We have great conversations.  We generate interesting thoughts an comments.  Those thoughts and comments get lost in the minutes from the phone calls or the hallway chats or the blog posts and notes from meetings.  How do I turn those things into more meaningful deliverables?

Some thoughts that I’ve had on this topic:

  • Each sub-team should have one person dedicated to gathering up content.  They should pull responses out of the minutes and into a wiki page or section.  They should glean the good stuff from the email chatter and add it to the wiki.  They would be responsible for rolling-up all the various bits and pieces that go by into a single reference point.
  • Each sub-team should have a set of deliverables as part of its charter.  For example, the Data Management sub-team agreed to deliver a survey and the survey results.
  • Each sub-team should produce some artifact(s) that can be shared with the world at large (e.g. a paper, or video or blog post) that others can consume on their own time.
  • I/we should have a standard way of “publishing” these deliverables and a standard set of ways of getting the news out that they have been published.
  • We should also be creative in our thoughts about how we engage beyond the core of ITANA.org.  Where does Twitter, Facebook, LinkedIn, the EDUCAUSE blogs and wikis, podcasts, screencasts, vodcasts, etc. fit into the mix?

That’s what I’ve been pondering.  Anyone have input?  I’d love to hear it.

Technorati Tags: , , , , ,

Brick Diagrams and related planning tools

 

Brick Diagram

Brick Diagram

Brick diagrams are a strategic planning tool that I mentioned in passing in my ITANA talk at EDUCAUSE.  Since then, I’ve had several people ask for more information.  So here it is… more information.

 

Brick Diagrams are used by NIH in their Enterprise Architecture planning process.  You can see the NIH brick diagrams and their taxonomy for the brick diagrams on the NIH EA Site.

Other institutions use similar planning tools.  Read on to see links to other places that use something similar and to download slides for a talk about Brick Diagrams that I gave to our Management Team.

Continue reading

SOA from the Registrar’s Perspective

Just had a hallway (okay, exhibit floor conversation) with Tom Black of Stanford University.  They have ideas on embedded enrollment functions in several places: inside their LMS, available via iPhone applications and elsewhere.  They would expose those enrollment functions as services then write to those services.  Interesting.  We also talked about orchestrating a flow, click on the drop button and you are passed to a short survey to see why you dropped.

This brought me back to the question in our session “Is SOA DOA?”.  I was asked how you get business leaders to buy into the SOA change and how do you get campus consumers to agree to work on SOA solutions.    Add to this the discussion with Karen Hanson, our Associate Registrar, on funding issues and how do we deal with costs of deploying SOA solutions.

It seems that there is a lot of interest in SOA in the Registrar’s world.

We may try to organize a meet-up after AACRAO in Chicago in April.  We could have Registrars bring their Architects for discussion around uses of SOA and issues with implementing, supporting and governing SOA.  It would also be good to hear their interesting Case Studies of how they are using SOA .

Things to follow-up on when I get home.

Technorati Tags: , , , ,