Architecture on Your Campus

Session Details, Presentations and Notes

Duke University - Kevin Miller &Mark McCahill

From Jim Phelps' blog...
Duke University

http://oit.duke.edu/tag/

Tech Architecture group at Duke is charged:
to track emerging technology and raise issues for the CIO's consideration
review major decisions
integrate into the project management lifecyle
pay attention and champion certain solutions
Developed small set of principles - few enough that they could remember them around four areas:
Data
Infrastructure
Services
Support
Each of these areas are highlighted in each principle's page (http://oit.duke.edu/tag/principles/p-robust-systems.html)

The principles:
Robust Secure Systems
Link don't copy
Design for scalability
Design for information lifecycles (not only the data but the overall system)
Adapt to realities of people and technology (has to work in real life)
There is tension between all of the principles. You are picking a failure mode when/if you don't meet a principles.

TAG drafted the principles. Focus groups used to refine the principles. The "adapt to the realities" principle came from the focus groups. Did an OIT-wide staff survey. Then followed a communications plan to evangelize the principles. They showed practical application via case studies - looked at situations that went badly or tough decisions that had to be made. The case studies are very valuable for communications and for the change management. They chose failures that where inside the group so that they would be criticizing themselves.

They also use Issue Reviews when there is a failure (http://oit.duke.edu/tag/issues/index.html). Each write-up has a list of recommendations with the principle highlighted.

The idea is build a volume of case-law and to evaluate the principles. "You're making stories... the legend that becomes part of the culture".

UW-Milwaukee - Michael Enstrom

From Jim Phelps' blog... Started the planning process in 2005-2006. Looked the leadership and the way that the serve campus. They also help support the UW-System.

Targeted the information flows between and within the academic, research and administrative areas. Engaged the leadership.

They hired staff with EA experience and repurposed staff with expertise. They then looked at frameworks to take advantage. The liked the TOGAF framework but streamlined it and made it more light-weight.

The EA Team has:
Chief Process Architect
Enterprise Data Architect (Michael Enstrom)
Operations Architect
Application Integration Architect
Security Architect
Network Technology Architect
Web Architect
Deputy CIO
Developed Architecture Principles in four areas; Business, Data, Application, Technology. Develop "IT Guiding Principles" for centralized and decentralized IT-Oriented staff ("how we'll function"). Defined the activities that we will follow together to put the Architectural Principles in place. Almost an SLA with the business partners.

Now doing a data/application/process inventories - huge pain, a lot of work. Trying to capture legacy information before people retire.

A lack of a consistent approach to requirements gathering leads to solutions that aren't based on deep understanding. The role of agile approach is to do it in smaller chunks. This helps align the requirements with the end-users needs. They have used the IIBA Requirements Management methodology. The CIO is paying for the training of people outside of IT so they all speak a common language.

They are looking at an "Emerging/Accepted/Best Practices" approach. Looking a broad suite of standard best practices. Evaluate the standards and see what they want to use.

Working on a method to bring every one to the table set priorities for funding and projects.

Saint Louis University - Jim Hooper

from Jim Phelps' blog... 2006 - was getting a lot of things done but they weren't connected. Lot's of talk about flexibility and agility. There was a lack of change control with "heroism at the interfaces". Lot of big projects going with and showing success: network, info shield, DHCP, Banner ERP upgrade, IDM. The CIO said, "show me some ROI" when she created her EA group.

Drivers for EA: mitigation of risks with the Banner Upgrade, regulations (SOX), lack of documentations. Started with the ITS shop first.

Governance included the 19 architects (domain and EA architects). The things that worked: the focus on People, Process and Technology. The PIM (Product Item Master) and the quarterly report of the PIM. Building relationships has been a focus for the past year or two. Created an Enterprise Infrastructure Working Group to manage the desktop image.

Using procurement to document savings.

Next Steps:

Architecture Gaps - they have reference architectures and the PIM but there are steps and layers missing between the two,
Governance Gaps - missing ties between strategic goals and the local technical choices,

The Control of the Work statement: what does that mean? Do you think the EA group will control the work? Means enterprise system / standards type context under the control.

How do we articulate the importance of "Architecture" regardless of the leadership and changes in leadership?