Tag Archives: SOA

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:

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

Agility – it keeps me up at night

Our last CIO, Annie Stunden, used to talk about “what keeps her up at night”. These were the big intractable things or the big high-risk, highly visible projects she was working on. For me, it’s agility. How does an enterprise that prides itself on tradition and autonomy of everyone at every level become agile – that is able to embrace change and implement new ideas and technology quickly.

Agility is the ability to change course or direction with ease and grace.  An agile athlete can cut and leap while making it look effortless.  An agile enterprise can implement new technologies or embrace changes in the world with ease and grace.  Universities are not thought of as being agile but rather the opposite – steeped in tradition and long-deliberating on new changes.

There was an announcement about a new (worthy) initiative to improve the education skills of our faculty. Faculty are highly trained in their fields. They have spent years becoming expert on some are of study. We hire them for their great intellectual achievements and their promising research careers. And then we ask them to teach a class. For many, this is the first time they have been asked to build and run a course. So, we have a new initiative to study  ways to improve the teaching skills of our new (and old) faculty. I fully support this effort in case there is any doubt. It is pretty easy to imagine a time-line that looks something like this:

  • Year 1:  Research and Planning
  • Year 2:  Implementation, pilot and roll-out
  • Years 3 – 4:  Early adopters and success stories
  • Years 5 – 6:  Majority adopters and general improvement

This is me guessing at the time-line but I think it makes approximate sense.  If, six years from now the new program for improving teaching and had reached 66% of the faculty and shown a improvement in overall education; it would be a great success.  I think that it is likely that it will do so.

What I think about when I hear of something like this is agility.  Students today have a laptop with 1GB of RAM, an 80 GB hard drive, 10 – 50 Mb/second wireless connections.  They have an iPod with 80 GB of storage with a screen that has a 640X480 screen.  Their cell phone has a web browser, MP3 player, camera, video camera and a suite of messaging clients (text messaging, voice messaging and email).  If we follow Ray Kurzweil’s thinking and  Moore’s Law; then the student who comes in at the end of this 6 year plan will have 2 to the 4th more computing power at their fingertips.  The 1 GB of RAM will be 16 GBs.  The network speed will be 160 – 1000 Mb/second wireless connections.  Their iPod and laptop both will hold a terabyte of information.  Their cell phone will have a high definition video camera and a 16Mb still camera.

These are just the attributes that are doubling – the capabilities increase dramatically as these technology pieces double.  What happens when I can point my laptop camera at an object, have it recognized and instantly retrieve high-def movies about the object to my cell phone?  What does that mean to instructional style?

The technology and the students are highly agile.  Vendors are designing products for launch 2 years out expecting technical capabilities to double in the meantime.   What is too big, too expensive and requires too much computing horsepower now; is perfectly reasonable 18 months from now.  The students who are entering college now have had access to the World Wide Web their entire educational life.  They have always been able to “look it up on the web”.

There is another project that is on-going here which I’ll call “anonymous”.  They are also on a 5 to 6 year adoption plan.  Their vision is to pick a standard software package and then hope that people migrate to it.  After 5 or 6 years, the majority adopters will be using the system and then more rigorous standards can be developed for its use.   This is a common approach in higher-ed where there is no top-down approach and where autonomy is highly valued.   The shortcomings of this approach are that: (1) it takes the approach that each software solution is a silo which has no effect on any other activity in the enterprise and (2) it assumes a stable environment – “we have 6 years for this to be adopted and that’s okay because much else won’t change over that time”.

Back to my student with 2 terabytes of data and high definition video capture and gigabit wireless everywhere – does a system we think of now take into account the rapid change of our user’s world?   I’m not a futurist but I do see, and I agree with Ray Kurzweil, that  paradigm shifts are coming more and more quickly.  The world is changing with greater and greater rapidity.  The way to deal with that change is through agility.  We need to be able to change with greater and greater agility.  Fortunately, technology can help us to some extent.

SOA and Web Services, when fully implemented, allow for changes in business process and new applications to happen at a much higher level in the enterprise.  These changes become almost configuration changes rather than whole new applications stacks that are implemented.  But technology is only part of the solution to this problem.

The greater more difficult problem has to do with culture change.  The academic culture is thick with individualism and heritage.  People still complain about changes that were made a decade ago or two or three.  This individualism allows our institutions to foster great experimentation and wonderful debate.  Faculty and students can state disagreeable viewpoints in the safety of the institution and their rights.  Departments can experiment with new ways to deliver their courses and information to the world.  Researchers can band together with whomever they want anywhere in the world to chase an idea.  All great and marvelous stuff.

But this leads to a belief system that has two elements: “You can implement any technology you want as long as I can do what ever want however I want”. And the partner belief, “you can implement a new system as long as I don’t have to change anything that I do.”

How do we become agile as an institution is this environment of individualism, autonomy and self-determination?  How do we shorten those projects from 6 years to 3 or 2?  How do we get people to see that each project is actually part of larger whole and that we each need to give a bit of autonomy to increase the overall functionality of the organization?  In some ways, our institution is more like a colony of early single-celled organisms.  Each one with its own complete functions.  Somehow we need to grow to that next stage where there is differentiation so we can move up the evolutionary tree.  That means that each cell will give up some functionality to become a specialist but overall all of the functions will be better carried out.

How do we become agile, not just technically but also organizationally, this is the issue that keeps me up at night.

EDUCAUSE SAC – SOA Presentation

This is a 90 minute presentation on Service Oriented Architecture that I gave at the EDUCAUSE Seminars on Academic Computing in Snowmass Village, Colorado. This talk was given on August 9, 2006

The link below is to the PDF version of the talk.

EDUCAUSE SAC Presentation on Service Oriented Architecture (PDF)

SOA as IT Portfolio process

In the SOA Migration Strategy planning, we are transitioning from DISCOVERY to PROJECT process (see the I.T. Portfolio Book). We will begin a series of projects to implement SOA in the near futureThe book talks about three models for DISCOVERY phase analysis:

  • Technology Maturity Modeling (Gartner Hype Curve)
  • See the example here: http://nnlm.gov/pnr/eval/rogers.html

  • Scenario Modeling – two flavors
  • Business Scenario Modeling, Business Event/Process Modeling

  • Road-map modeling

In the Technology Maturity Model, several pieces of the Web Services stack are fairly mature at this time, others are still in early stages. Overall, there is a belief that the technology is sufficiently mature that we should begin to implement.

In the Road-Map model:

  • At some point in time in the future (say 5 years), we will implement Fusion based SIS, SFS and other software (probably)
  • This will instantly make us neck deep in in the WS-* stack, BPEL and MOM
  • Given this fairly sure hard milestone in the future, we should develop a roadmap that will make us mature in this technology on or before this event.

The Scenario model is under-developed at this time.

We have an opportunity to take SOA Migration through the I.T. Portfolio processes for each phase and to think about the analysis that should occur at each step of the phase.

U-Minn presentations: SOA, Folksonomy and IT Architecture

On Monday (April 3, 2006), I was at University of Minnesota presenting on four topics. Below are links to the slides as PDFs:

  1. UW-Madison’s SOA Migration Strategy – what is it and how do we get one
  2. Folksonomy and Web 2.0
  3. IT Architecture – What is it and why 3 isn’t enough
  4. Identity Management Nouns and Verbs

Note that the Folksonomy slides are from an Internet2 version of the talk and are more inclusive than the slides I used at U-Minn. Actually, I meant to grab these slides not the ones that I used. There are a list of links of the URLs that I used in the Folksonomy demo here:

Links I Use in My Folksonomy Demo

Three forces for migration to SOA

There are three forces that we can bring to bear to push change to a Service Oriented Architecture.

(1) Architectural Purity

>This is the force of arguing that it is the right thing to do. You can state a lot of reasons why it is the right thing to do like: composite applications, workflow, ROI, integration cost reduction, etc. Basically, you stand on high ground and preach that this is the correct approach. This is a difficult sell to pull off especially in a heterogeneous and feudal enterprise like a higher education institution.

(2) Consumer Request

>This is force of the consumer of the information or service asking for a new way of getting information. The statement goes something like, “I need to know X from your system. I would prefer to get that information in a Web Service rather than a flat file.” The reasons for making this argument may have to do with timeliness of data (it needs to be up-to-date at this moment) or ownership of the business rules (e.g. you have all of the data to determine if X is true so you should just provide the answer instead of sending me the data so I can derive the answer) or possibly wanting to be on the front edge of technology.

(3) Provider Demand

>This is the force of the data provider (or source or system of record) deciding they will no longer support older interface styles (flat file transfers et al) and instead will only support a Web service interface. This argument can bring to bear cost incentives. The provider can state, “if you use the Web service, we will make sure that the Web service is upgrade and updated. If you must have a flat-file, then you must pay for all of the work to develop, maintain and deliver the file”. They can also bring policy enforcement into play. “Any request for a flat-file will be reviewed and you will have to make an argument why you must have the flat file rather than use our Web service”.

The Provider Demand force is the one that has the most weight behind it and is the one that is mostly like to carry day. We can argue about the Architectural Purity of a SOA and we can request Web services but that will fall on deaf ears or at least un-funded ears. When the data providers demand that the data consumers use their Services or pay the bill, then we will see rapid adoption of SOA.