Enterprise Abstraction

On a simple EA governance process

When we first embarked on the "EA Adventure" we'd received a goodly deal of in-house training and consultation - and we followed up on that with lots of reading and conference attendance.  All of these sources stressed the importance of architecture governance - and we agreed - an architecture that isn't followed or implemented is less than worthless.  However, few of our sources offered any suggestions on how to actually execute that portion of the process. 

We were particularly concerned that our organization is a rather small one - and our architecture group is proportionately diminutive - we wanted to reduce the amount of time spent on governance to a minimum.  Moreover - there was concern that the architecture group itself does not really have any direct decision making authority with regard to projects.

We established what we'd considered a pragmatic process for governing architecture alignment (then called compliance) in projects.  It essentially involved reviewing a project at 1) the planning stage, and during the 2) software design and 3) development stages.  Performing the review would be a committee - the Architecture Review Team - consisting of the architects and various heads within the technology department.  The project manager or technical lead would demonstrate the relevant parts of the project to the committee, and we would evaluate the project's alignment based on our standards, models and principles.  Good right? 

Of dozens of small projects - we successfully completed 2 partial reviews in 3 years - and neither of those reviews were actually successful in creating any sort of positive change in the projects.  So, what were some of the problems?

Firstly - we'd not really established the fact that our efforts should be guided from the very beginning of an initiative -- at the project proposal stage -- by architecture.

Secondly, the section heads that we'd invited to participate in the committee were not particularly well versed in the architecture, or architecture process.  They felt that they could contribute very little to the governance process.  Only the architects - involved in the depth and breadth of the architecture could really have an up-to-date understanding of the architecture to make informed decisions. 

Finally - getting that large group together to perform a review was an exercise in logistics.

Hence, not a terribly successful first attempt.  We couldn't review the projects early - when we could have the most positive impact before a project had already established a scope and plan - and we couldn't perform reviews in a timely fashion - it taking so much time to arrange meetings, review the material and keep up to date on architecture.  Most importantly - we felt we were wasting a lot of time for little impact.

How did we make it work better?  We abolished the malfunctioning Architecture Review Team - and replaced it by having an architect assigned to each project that was responsible from beginning to end in tracking the alignment - from proposal to close.  The architect ideally helps to write or consult on the project proposal and plan - and establishes which architecture components would be implemented by the project (if any), and keep track that the project was meeting established technology standards and architecture principles.

If there is an alignment issue - it's brought first to the technology lead or project manager - either directly or in a team meeting.  Failing a resolution at that level the issue can be reported to the project review committee (a committee that's assigned to oversee individual projects -- to help remove roadblocks and provide guidance).  Failing a resolution of the issue at that level - the problem is presented to the project sponsor and/or the corporate management team.

It's a reasonably nimble process - relying mainly on the resource availability of the architect (easily managed), and taps into the authority already existing in the project management and project portfolio processes already in place.

At this point in our second attempt at architecture governance - things seem to be going well.  We're currently tracking the alignment of at least 50% of the ongoing projects - and likely 100% of the architecturally significant ones.  Recommendations are more easily accepted - and in the few cases where there have been serious issues - they have been resolved reasonably quickly.

I'm crossing my fingers for continued success.

Extinction timeline and libraries

For just a moment, I thought the Slashdot Article Can Architects Save Libraries From the Internet was more closely linked to my field than to the "building buildings" kind.  However the Extinction Timeline they link is quite interesting anyway.  Libraries dead in another 11 years?  I think that's perhaps a little pessimistic.

Well, even if true, I hope that libraries will undergo some evolution before then, and perhaps merge as a slightly different species.

Greg the Architect - Off the Grid

Greg the Architect has a new episode entitled Off the Grid.  I love this thing, though I imagine there's a fairly limited audience for the material.  I guess it fits with my fondness for the South Park and Robot Chicken genre, but it's even a little closer to home due to the subject matter.

Those darn business analysts... I knew it... I knew it all along!

Job Posting - Technology Architect - IT

Interested in libraries and architecture?  Perhaps you'd be interested in the recent job posting for an architecture position at CISTI?  Despite the job title - Technology Architect - the position is really about enterprise architecture, SOA and the like. 

Stats Canada IT Conference 2007

John told me about a conference that Statistics Canada is hosting - the IT Conference 2007.  According to the call for papers and programme, it's very much about enterprise architecture and service oriented architecture this year.  I'm sorry I hadn't been aware of it earlier... oh well.

Looks like a good program.  You can register here.

Greg the Architect

I just discovered Greg the Architect over on ZDNet's SOA blog.  See Video 1 and Video 2 over on YouTube.  Hilarious.  It's funny cause it's true.

EA single line definition

Bill Barr proposed a single line definition of Enterprise Architecture, and I'd like to follow his attempt (not that I consider myself at all qualified):

Enterprise architecture is the planning process of an organization that leads to the implementation of business strategy and processes.

I've intentionally left out the words technology and models.  Models are tools for communication and doucmentation.  Technology is a tool that is often used these days to achieve the ultimate goal of enterprise architecture.  EA could be equally applied to a lemonade stand as it could to a multi-national corporation, the methodology remains the same.  Architecture is not, ultimately, about technology... though it is very practical to use EA as a planning tool that, of course, often includes technology as a very important aspect.

Wikipedia provides quite a good definition that's perhaps more accurate and less broad than mine:

Enterprise architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization's processes, information systems, personnel and organizational sub-units, so that they align with the organization's core goals and strategic direction.

The technology aspect that tends to be applied to EA I find blinds many to it's true objective.  Technology is really just a means to an end.  Perhaps a less zealous way to state things might be that Enterprise Architecture is equally concerned with people and business processes as it is with technology.

Library Architecture Principles

Michael Ridley points out an excellent article in Library Journal by Roy Tennant where Roy mentions a few thoughts that I think could be adopted as architecture principles.  In particular, I like:

• Build not for longevity but obsolescence
• If it doesn't have an API, it's not worth having

And one more that he does not explicitly mention, but that I think is a very important one for organizations newly undertaking architecture and technology practices:  become comfortable with the not knowing.

All too often I've seen all sorts of projects and initiatives fail due to the very human desire (some would say need) to know it all up-front.  This is impossible.  Deal with it. 

Yes, the architect will work with you to provide a broad scheme... blueprints if you will for the planned vision.  This is not a detailed plan, just an overview.  There are still risks, and unknowns.  As you work though the plan (via projects), you identify and manage the risk.  You cannot -- must not -- stall progress until all the unknowns are known.  You'll wait forever.

Business Architect - Not

I got a little ill when James Tarbell pointed out a terrible abuse of the term business architecture.  He points to a couple of, what are essentially advertisements, which include statements such as:

    Business architect [sic] is a person that initiates new business ventures or leads business innovation, designs a winning business model, and builds a sustainable balanced business system for a lasting success.

    Business architects can be found in a multitude of business settings: corporate change leaders, initiators of joint ventures, managers of radical innovation projects, in-company ventures, spin-outs, or new start-up ventures.

Although I realize the hypocrisy of it, I do hate it when buzz-phrases are co-opted in this manner.  I whole heartedly admit that we stole "engineering" and "architecture" from other fields.... but I argue that there was a serious difference in intent. 

Thanks for the afternoon laugh James.

DLF Services Working Group Workshop

I attended a workshop held by the Digital Library Federation's Services Framework Working Group, held November 7, 2006.  Finally, my kinda initiative.  Libraries, technology, architecture, SOA, all combined into one nifty group working together for the common good of mankind.  I get the warm fuzzies just thinking about it.

The workshop was essentially a pre-conference for the DLF fall forum 2006, that was held last week in Boston. 

My impression was that the working group has done a lot of good work thus far, and I'm very pleased that a group is looking at bringing architecture principles to libraries on a more global scale.

My experience with enterprise architecture and SOA within one library/enterprise -- namely CISTI -- has been quite successful by all accounts.  However, that success has been largely won based on a huge communication and education effort, by accepting risks and uncertainties, and by an unending effort to garner buy-in from both management and staff at all levels.  I'm concerned that the Services Working Group has it's work cut-out for it in attempting to achieve a more universal acceptance of what is essentially a high-level library architecture effort.

The main criticism I would posit is that if you're doing an effort such as this, to capture the common business processes of libraries, then please don't make up a process or methodology.  The skills, training  and methodologies exist to do enterprise architecture (or, perhaps in this case - meta-enterprise architecture). 

Also data flow models are not passé.  Don't make things complex that can be simple.  Most times I find that if you can identify the business process, data, data flow and actors... you've solved your problem.  :)

A framework should be developed at a particularly high level, encompassing only the common and agreed upon elements of library processes.  Whilst you may need to dig deep to collect and confirm processes, the framework itself, I suggest, should remain fairly high -- providing individual enterprises the ability to compare, contrast and build upon that framework in their own context.  That said, libraries have been around for a very long time, I'm certain that libraries have many business processes that they commonly share.

What am I saying?  I'm saying there are at least 2 levels of architecture here.  The high level meta-architecture (framework) thats generally agreed upon amongst libraries, and then there's a true enterprise-level architecture that's needed within an institution to meet specific needs.  The enterprise-level architecture should, ideally, use the framework to guide their architecture development and implementations... but a framework can never fully accommodate the specific business needs, planning and implementation required within an organization.  That said, it was very clear from the paper published in DLib Magazine and during the workshop that the Services Working Group in no way was attempting to delve too deep here.  What I'm saying is that libraries should get some architects on board and within their planning and technology groups, and perhaps the Services Working Group could attract some architects to assist them in their valiant efforts.

Another thought:  Who the client/user is for this architecture.  The client, ultimately, is the patron -- not the librarian, I think.  Is this true?  I always find it easier to attack these questions from the end-user perspective first.  Argue with me.

Overall, I believe that it is a timely, well-needed and important effort.  I'm hoping for its success.

For more information please consult the Digital Library Federations Services Working Group page, and the Education Commons DLF Services Framework site.

Check out some of my photos around Boston that I took during the workshop.  It's a beautiful city to inspire thought.