EA as S talks about four operational models. These four models are defined by the level of unified business process and the level of data integration. See figure 1.
EA as S also talks about "four stages of architectural maturity."
EA as S applies their operational model to the enterprise as a whole. Once you have decided your enterprise's operational model, then you decide which business processes and data are needed to support the model. You then move those process and interfaces through the stages of the maturity model.
EA as S emphasizes that the choice of operating model and the map of supporting processes and interfaces must be done by a team of business process owners and leaders across the enterprise. These decisions must be broadly supported if you want to get buy-in.
As I admitted on the phone call, I use this framework in a different way in my discussions on campus.
First: I see UW-Madison as a set of vertical operations rather than a single enterprise. Some portions are highly unified or moving in that direction (Undergraduate / Graduate Student Admissions and Enrollment). Some portions are in Coordination (Research, Education). Other portions are highly Diversified - mostly due to culture not technical need.
Second: I focus my energy on those portions that are in either the Unified or Coordinated realms or those that are moving in that direction.
Third: I work with owners and stakeholders of various vertical operations to work out the "what is core" and "what are common business process" discussions. I don't do this as an enterprise-wide discussion. I do think that the enterprise-wide discussion would be good but we haven't (yet) rallied the political will to have that discussion... and then enforce and implement the outcome.
By focusing on narrow groups within the enterprise, I can actually find owners and stakeholders who are willing to have the conversation and willing to make the changes that are described. My hope is that these local improvements raise the awareness of the methodology. Hopefully, after some success, other groups will want to come on board. The local issues will be resolved but the cross-group issues will still exist. The pain of not having the framework worked out across the enterprise will become apparent.
Lastly: we are very early on. I have one group who is a very willing partner. I hope to work with them in their next strategy session on this framework and analysis of their vertical.
Course Roster Interface Service
Current state: people are getting course roster data how ever they can. Some have feeds from the Student Information System (ISIS). Others run reports against the data warehouse. Others are re-purposing flat-files that they can get (like a mailing label file).
Issue: We have different definition of "A Course", the changes in enrollment are late or incorrect (see Example of the problem) and courses are mapped (joining of sections) differently in different services based on the services solution rather than an agreed upon business process.
Example problem: We had a crisis where a major system was getting data that they thought was good only to find out they weren't getting drops. Students were calling the Registrar's Office complaining that their professor says, "their still enrolled" though they dropped weeks ago. The students were worried that their hours would be off or that they would get a bad grade. The Registrar's Office had no idea that the major system had pulled data which was incorrect. The major system did not talk to the RO prior to building their feed.
My EA as S Take: This is an area that is going from Diversified to Coordinated. This is moving from everyone doing their own thing to a standardized business process for mapping courses to sections and for joining sections and to a standardized representation of the data. We will move people from many different interfaces to a single interface.
The Roadmap: First: Create a standard data file for Course Roster Data. Move the services to a single flat file that they all get. (Standardize the data representation). Second: Move to a Web Services to retrieve the file. Parse the data that each service gets to only the data that they need (Move to a common interface). Third: Switch to an Event-Driven Architecture where possible. Move the mapping rules into a middle-tier application so that all services are joining data in the same way (Unify the Business Rules and move to a SOA).
This is a low level example but it is a place where we introduced the vocabulary. Course Roster data is Core to the enterprise. The uses are Diversified. We need to standardize the business process. etc. Since people have localized pain (they wanted to run services in their departments that needed course roster data) they were will to talk about the larger issues of moving from a diversified solution to a coordinated solution.
Division of Enrollment Management
Current state: DEM is a great campus partner and a willing participant. They are my champions for enterprise architecture. They cover the full lifecycle of a student. They gather information on prospective students, handle their applications, enroll them courses and generate grades and transcripts once they leave.
Issue: Parts of DEM view themselves as silos.
Example problem: A document scanning and workflow application (ImageNow) was purchased to handle the paper documents that we get from applicants. The procurement project was really focusing on the needs of the group not the campus at large. It was pointed out that they would "have the core data about the incoming students" and that "departments would need access to this data". Marvelously, these weren't my words but the words of a campus committee to whom they were giving a presentation. This same application is also used by Human Resources for the paper files that they get for employees.
My EA as S Take: Another silo solution that suddenly moved up into the Unified realm as people started to see that they would need have common business processes (who gets to add what notes, who reviews, who has access, how do SSNs get redacted, etc) and a common data access system.
Another slightly higher project that lets me get the vocabulary and thought process on the table.
Campus Wide Policy
Current state: We have a few campus-wide policies. Most of these are driven by outside forces like the federal and state governments. Policies get enforcement weight when the FBI is involved. We have a weak process for setting policies and an even weaker process for enforcement.
Issue: People don't know how policies are set. We set policies in an ad hoc - this is at the top of the list - fashion rather than a more deliberate "this is the state we would like to operate in" fashion.
Example problem: There was an initial meeting to discuss "how do we do this policy setting and governance thing". I'm not sure there is a big problem just an opportunity.
My EA as S Take: We should first talk about our operational model. We should pick those areas that we would like to move to the core of the enterprise operational model and focus on the policies that are needed to make that move or support that move. I think this would ground the policy setting and governance discussion in strategy that affects the whole enterprise rather than a pain-point by pain-point process (Aaahh! We need a policy to stop this in response to this mandate.)
The CRIS section looks fine. In the policy section, it might be politic to give IMLG their due: Identity and Access Management is an area where our generally shared goal state is probably "optimized core." The fact that policy development (if not enforcement) is thus more mature than in other areas then makes sense.