2009 April | Enterprise Architecture in Higher Education

SOA Governance by Todd Biske – book review

book review, enterprise architecture, it governance 1 Response »

Apr 112009

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.

I like Todd’s definition of governance:

“Governance is the use of people, process and policy to change behaviour.”

Seems obvious when you read it but how many times to we just rush ahead focusing on one or maybe two things while completely ignoring the other, with results that are much less than what we expected?

Thanks for all your time and effort to put this book together Todd. It will be a valuable reference for me and my team as we work to move into a Service Oriented Architecture.

How deep do you go?

enterprise architecture, it governance, strategic planning No Responses »

Apr 072009

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.

I have been working on a strategic planning exercise with our Human Resources department. I am taking an approach that my friend David Bedwell developed at Charles Sturt University in Australia to build out their Enterprise Architecture. I started with a discussion about the basics of EA – think Zachman interrogatives:

What = Data
How = Process
Where = Systems
Who = People
When = Events
Why = Strategy

Thinking about these primatives Process is change resistant. For example, if the HR department replaced employee recruitment services with facilities management services, would this group still be an HR organization?

Here is the diagram showed our HR folks to introduce the concept that process is the centre:

By using Process as our base foundation, we can layer onto it Strategy, People, Events, Data and Systems. I tried this with Systems as a test with the HR team and it was very apparent that our current Application Portfolio does not support all the key processes delivered by HR. By showing this on a diagram, we can articulate “roadmap” projects to close the gap in function/capability in our systems. I will write more about this process as we work our way through it.

I will also work on articulating “how deep do you go.” I am very interested if you have a set of standard questions you get from your business folks and hope you will share them.