Recently, there has been several blog posts discussing what should and should not be done when building an EA practice. I thought I would review how we built our EA practice in our higher education organization and compare it to some of the other approaches. I have yet to see one definintive approach for all organizations. EA is a cultural thing and needs to be implemented in the context and culture of an enterprise.
We started thinking about Enterprise Architecture when the Institute developed a strategic initiative to leverage technology to transform, enhance and support teaching, learning, research and business at the British Columbia Institute of Technology. As we put together the business case for the initiative, the consultants helping us suggested we adopt an EA approach. Four staff members (including me) were selected to spend a week with John Zachman and Stan Locke taking Zachman’s EA Fundamentals course. Right away, I was hooked. When we returned, the Institute created an Enterprise Architect position to help plan and architect the strategic initiative. After a selection process, I was selected as our first Enterprise Architect. Read more...
I had a great phone call with Roger Sessions (@RSessions), CTO ObjectWatch a month ago about IT Complexity. Over the past few weeks, I got a chance to read about Roger’s approach Simple Iterative Partitions (SIP) in a series of white papers:
Some key points that resonated with me:
- Autonomous Business Capabilities (ABC)
- Mathematical Basis for Understanding Complexity
Years ago, we used a simplified model to articulate why we needed to build our Enterprise Architecture practice. The central premise of the argument was that as functionality increases so does complexity. We proposed using IT Governance and Enterprise Architecture to manage complexity. See the slides here.
Roger has published a new white paper – The IT Complexity Crisis: Danger and Opportunity on October 22, 2009. The main sections of the paper are: Read more...
- The Coming IT Meltdown – calculating the costs
- Cause of Failure – measuring IT complexity
- Designing Simpler IT Systems
- Impediments to Simplicity
- Call to Action
Reading Roger Sessions (@RSessions) work on IT Complexity reminded me of a set of slides we created to articulate the value of IT Governance and Enterprise Architecture.
We (my colleague Dave Cresswell and I) used a simplified model to articulate why we needed to build our Enterprise Architecture practice. The central premise of the argument was that as functionality increases so does complexity. We proposed using IT Governance and Enterprise Architecture to help manage complexity. The slides resonated well with our senior leadership and in the many EA talks I have given over the years.
The example we use in the slides involves the change in functionality of collaboration services. (Note the curves shown are representative and not based on statistical data – so please no complaints about statisical significance) The slides show how collaboration functionality increased over time from green screen, text only email on the mainframe (IBM PROFS) through client server email (Lotus Notes) to fully web enabled collaboration spaces and community of practices. Unfortunately, the IT architectures used to deliver the new functionality increased in complexity at an even quicker rate. Where the two curves cross is a point of diminishing returns because more effort is spent managing the complexity resulting in no resources available to deliver the new functionality. Read more...
I am back at the University of Alaska Fairbanks this week to collaborate on IT Service Management with a focus on:
- service definition
- service delivery
- service catalogue.
I will also be a presenter at Univeristy of Alaska Office of Information Technology 3rd Annual Techfest 2009 talking about BCIT’s Technology Enabled Knowledge (TEK) strategic initiative that wrapped up this spring. I has been just over a year since my first visit and I am keen to work with my colleagues again. Will blog more later in the week.
On August 11th, Gartner announced a “new approach for enterprise architecture” that they labelled “Emergent Architecture”. I got a chance to read some responses from Todd Biske, Mike Rollings, and Dion Hinchcliffe. Thanks for the great insights and commentary.
In the press release, Bruce Robertson, Gartner Research VP states the two characteristics of “Emergent EA”:
- “Architect the lines, not the boxes – which means managing the connections between the different parts of the business rather than the actual parts of the business themselves.”
- “It models all relationships as interactions via some set of interfaces, which can be informal and manual”
On characteristic 1. is if you only look at the connections between parts of the business, how can you look for opportunities to reduce complexity, increase efficiency and implement reusability? I believe enterprise architecture is about the whole organization and its environment, not just pieces of it. As an example, our EA practice encompasses IT Service Management (ITIL), Business Analysis (BA) and Program Management (PMO).
On characteristic 2. , again all this says to me is to take a “user experience” approach to describing the architecture. This is nothing new as far as I can tell … perhaps I am missing something? Read more...
I talked about a governance model that has evolved over the past 5 years in our organization in many previous posts. I realize now that I have not actually explained the model, so here we go!
When we received approval to proceed with a strategic initiative to leverage technology to support teaching, learning, research and the business of BCIT, our VP Chris Golding came up with a simple governance model to guide technology adoption.
The model has 3 axes – Funding, Support and Impact. The scale for the axes range from centralized to decentralized. Let me give you some definitions before we look at the model. I am sure there are many other scales we could describe for this model but there is an elegance in these 3 simple descriptors.
Funding – describes where the funding is coming from on a continum of centralized (we are a centralized IT organization) to decentralized.
Support- describes where the support comes from on a continuum of centralized to decentralized (where in the Institute do the people who support the technology work).
Control - describes where impact or risk is managed from on a continuum of centralized to decentralized (where in the Institute does the responsibility and accountability reside). Read more...
Mike Kavis posted another great piece on why we should use Enterprise Architecture. As always, Mike has some real gems in his post. Here are a some:
- “It sounds to me like people have a technical solution and are now looking for a problem to solve with it. It needs to work the other way around!”
- “Well, coming to the business with technical solutions asking for help to justify them with business drivers is not alignment.”
- “At this point the ROI should be much easier, because the solutions were driven by the problem statement(s), not the other way around.”
- “Without this alignment, IT will constantly struggle to sell technical solutions to the business and come up with appealing ROIs.”
With the recent economic situation, business leaders are looking more and more to IT leaders to help enable cost savings and business performance. In my regular meetings with my business colleagues, this is becoming a consistent theme. The only way this will happen is for IT leaders to sit with business leaders and understand their issues and problems. Once this problem is understood, then the IT leader can bring to bear the appropriate technology solution. The ROI is put back on the business (where it belongs) and how the problem is solved not on the technology that enables the problem solving. Read more...
I have been following Todd Biske ( @toddbiske) for a few years now. I was in Orlando in Oct 2008 teaching a full day course on EA in Higher Education at the Annual Educause 2008 conference and I met Mike Kavis ( @madgreek65) for lunch (via Twitter but that is another story). We talked about a bunch of EA and SOA things and he recommended Todd’s book – SOA Governance. One thing lead to another and I did not get a chance to order it until Jan 2009. Just finished reading it and found it to be an excellent start for the SOA initiative that we will be launching.
Over the past couple of years, we have made small attempts at SOA by building a few services to expose ERP functionality to our public web properties. After some discussion with our EA Solutions Council, we made an architectural decision to move away from our public web making direct calls to our backend ERP database and instead provision standards based services. Now that we will begin focusing on a formal SOA adoption strategy and I plan on leveraging Todd’s book to help us move forward and potentially avoid some of the pitfalls. Read more...
Nick Malik just posted about All the questions fit to answer …
“Make sure you write down the questions that the business wants the Enterprise Architecture team to answer. Then collect only the information that you need to collect in order to answer them.”
… and it triggered something that I have been thinking about for a long time.
How deep do you go in capturing your Enterprise Architecture? At what depth of detail (or abstraction), do you go to ensure that you have enough to support Strategic Planning (like Nick talks about) and IT Governance? At what point have you gone too deep, making your EA practice into a resource sucking documentation exercise?
During our lunch last week, Nick talked about Business Capabilities as an abstraction layer. I am sure Nick is going to blog about this in the future. We are putting together a Institutional new strategic plan in the next few months and I plan on writing down those business questions. We should then be able to look at our EA artifacts like our Application Portfolio and see the gaps. More importantly, we should be able to determine data we are capturing that do not provide value or help in answering the questions. Read more...
In this post, I will describe the IT governance committee for small and medium projects, their terms of reference and the scoring system for ranking projects. In September 2007, we started a process to use IT governance to help us manage the flood of proposals and project requests. Thanks to my colleagues Gary Lake and Dave Cresswell who did the heavy lifting and put the process in place.
The Business Applications Advisory Committee (BAAC) gives advice and guidance to IT Services on which project requests would be the “right things” to do; recognizing that we have limited resources and want to focus them on the work that will deliver the most value to our community.
BAAC Terms of Reference
Business Application Advisory Committee advises Information Technology Services on the priorities for small to medium sized business application proposals that will further the goals and strategies of BCIT.
We define two types of business application projects: Major and Minor. Major projects are referred to the BCIT Executive Leadership team for governance. Minor projects are referred to the BAAC for ranking.
Minor projects are defined as: Read more...
- projects that will improve BCIT business processes and are not part of routine maintenance or operational activities of IT Services