EA to facilitate change

This Enterprise Architecture Gartner report states:

"Decisions may be heavily influenced by a business context and the organisation’s business landscape, people and politics, future state vision and experience. Regardless of the approach, EA must facilitate change. The key is to create, not the perfect or elegant architecture for the moment, but the most adaptable architecture for the future"

Which in my opinion is a great goal for EA - to facilitate change, to be adaptable and not to get into a vicious circle of defining an architecture down to the nth degree. This links back to a question of when do you know you've done enough? I don't think the answer lies in the question of when is enough enough, but rather in being more aware of how the products from EA are being used and adapting the EA work to assist the business in planning change. I have often seen great initial deliverables that have helped the business down a journey. But these first successes are followed by a split where the EA team goes off based on that outcome to try and create the elegant architecture and the business trots off in another direction to work on the organisational change management and when this happens EA loses its relevance.

I do wonder if some of this is due to short sighted EA consultancies looking to stay engaged with the ICT-side of the house, because in most organisations this is the organisation that has bought off on at least exploring the EA path. This easier path to a longer engagement results in spending time creating products that may not be relevant at the end of the day. As 10cc wrote:

"Art for arts sake, Money for gods sake
Money talks so listen to it, Money talks to me
Anyone can understand it, Money can’t be beat oh no
When you get down, down to the root
Don’t give a damn don’t give a hoot
Still gotta keep makin the loot"

This type of thinking may end up with people losing patience with EA efforts and considering them irrelevant. EA really needs to bridge ICT with other business support organisations and business operations to show relevance to all. By being engaged with all aspects of the business, in other words 'the enterprise', and being flexible in your EA approach based upon where the business is exploring change, EA will show value by being able to facilitate that business change.

Communication Primitives - SHeet Music for IT Professionals - But what about the User?

Defense Systems recently published an article DOD turns to basic building blocks for a common language, that describes Business Transformation Agency's approach to overcoming the language barriers inherent in the system development process - Primitives.

Primitives are common vocabulary and common design patterns, which can be used to describe business processes, information and data in a notation. They are intended to be understandable to a wide variety of people involved in system development, much like sheet music provides a universal notation for musicians. This initiative supports the need to align all layers of the enterprise architecture with a common vocabulary or notation set, which is certainly an integral part to improving system development. In the US DOD the Business Transformation Agency (BTA) is using primitives for enterprise architecture, business process training and simulation.

It is time that greater commonality be found between the various disciplines related to system development and the concept of a global language for IT professionals is a great one. I like the analogy of the sheet music because it can be extended to the end user. In the case of music the end user does not need to be able to read sheet music to appreciate the output. This is also the case with IT outputs. In some cases the user reaction to the "music" is easy to gauge, kind of like a music single - iPhone apps, video games and to a certain extent office productivity tools. In other cases, like many enterprise systems, the "music" presented is more complex than an opera or the works of Greek bards like Homer and frequently this complexity is increased due to the intermixing and overlapping of various pieces. This may result in a user experience much like the one viewers were presented in Star Trek Next Generation when Data was listening to four songs at the same time.


This complexity makes it much harder to keep the focus of the user's attention. In the world of enterprise applications there is a need to be more proactive in gauging user reaction, not just to focus on function points but to the overall user experience. A need to strive to present "music" that they would sit down and listen to or get up and dance to - whichever they prefer.

Visualisation - Ideas for communication

When trying to share ideas across a broad spectrum of stakeholders, information visualisation techniques can be very useful. I recently came across Fantastic Information Architecture and Data Visualization Resources and I found some of the visualisations inspiring.

Another site that brings out powerful world demographic visualisaitons is Gapminder

This talk from Chris Jordan on www.ted.com uses visualisation to help people grasp how our actions affect the world around us.

Modelling - It's all about communication

UML, BPMN, JML, IDEF, Information Engineering and many more... Looking at software development methodologies there are a number of modelling languages to choose from. Many of the languages are dependant upon the target software technology but the key objective of the language is to communicate.

Many times I see people become engrossed with a particular modelling language and lose sight of the objective to provide a communication tool for all stakeholders. Don't get me wrong there is a place for formals models that abide by the standard when communicating with other people who also are familiar with the model syntax, they allow software engineers to consider design options and determine an appropriate development approach... but sometimes the focus of the modelling effort goes into tweaking models to the nth degree. This search for the perfect model rarely assists in developing better code, nor does it assist in providing communication outlets that engage the non-technology stakeholders.

What techniques do you use to assist with communicating the application design with the non-technical stakeholders? How do you confirm that the design tracks back to the business need? Prototyping and agile development methods look to get the user buy-in through interaction with prototypes but is there a way to blend agile approaches with modelling approaches?

Back in 1998 Keith Harmon and Alan Perkins compared Object-Orientation and Business-Driven Information Engineering and came to the conclusion that the approaches were symbiotic as Business-driven Information Engineering is a technology neutral and reflect the business goals of the enterprise. Similarily, when looking at UML and IDEF Ovidiu S. Noran at Griffith University concluded that there is no one perfect tool that will do everything but it is up to people to select the right tool for the job and Kim found IDEF and UML to be complimentary in the article the complementary use of IDEF and UML modelling approaches.

I share the belief that there is not an obermodelling language out there and sometimes a blend of modelling approaches - some "official" and some that work for the stakeholders will bring together a design portfolio that will enable all stakeholders to actively engage in the design effort.

Working with Silos

I came across a video from Burton Group with Lyn Robison discussing how silos are here to stay and looking at approaches to bridging the silos as opposed to trying to break-down the silos.




Although this video looked at silos from a technology standpoint. You could look at business silos where you could apply Service-Oriented concepts to bridge business processes gaps as well as knowledge silos where you could apply social networking concepts and solutions to assist with exposing "tribal knowledge", bringing together people with shared interests as well as mining for subject matter experts that may previously have been buried within a business unit and lost to the overall enterprise.

IT has spawned many methodologies/approaches/modelling techniques for analysing business needs from an IT-perspective, organisations have implemented/developed multiple business process improvement methodologies and each industry vertical or function may lend itself to different methodologies. The challenge for us now is to embrace the variety and bridge these methodology silos. Any ideas?

My Blog & Article Picks for 2009

Here's a look at some of the blogs/articles that caught my attention in 2009:

A very different view of IT and Transparency from a Developing Nation - a look at the challenges of IT projects in a large Indian jurisdiction where IT has been traditionally about infrastructure.

IT Alignment over the years, the story and history series Part 1, Part 2 and Part 3 - where we are taken through the YMCA technology staff's journey focusing on the culture surrounding technology.

IT Savvy - Time for a Change? - a look at the change in organisations to be more fleet of foot positioning Enterprise Architecture, Governance and Program Management as mechanisms to support the change.

Business-IT Alignment: Time for a paradigm shift - a look at SOA's impact on the old Business-IT alignment focus

EA Value Contribution - looking at the value EA can contribute to support projects, strategic direction and portfolio transformation

Enterprise Alignment - Value Creation - the Next Institute's perspective on how to develop a creative and sustainable enterprise

See you in 2010.

Alignment - Why is IT singled out?

Everywhere you look these days, there are articles stressing the need for business and IT alignment. A CIO.com article calls it the 'holy grail'.

Why is IT singled out in the call for alignment and what exactly is 'the business'? In his blog, Joe McKendrick claims that IT is part of the business and therefore alignment is not an appropriate goal for IT. I tend to look at a business in two parts: one is the operations-side, focusing on producing outcomes for the companies clients and the other provides support to the operations and monitors compliance with regulations. This support side typically includes Finance, Human Resources and IT. Why is then that when I searched on "Finance Business Alignment" the articles I found were on managing the IT portfolio expenditure not how the finance function may better support the operational outcomes of the business?

Like IT, both Finance and HR are endeavouring to free-up resources from transactional processes to enable investment in providing strategic services to optimise operations. This is coined as "Strategic HR" or "Strategic Finance". Is there a difference between the end state, which is being sought after through business-IT alignment and what could be coined as "Strategic IT"?

If the true intent of business-IT alignment is for IT to be a strategic partner, where does this leave the idea of alignment? Isn't the selection of "Enterprise Alignment" as a blog name somewhat inappropriate? Maybe, but in my travels implementing bespoke and ERP systems in large enterprises, I have seen many disconnects in business processes. Some of these disconnects were between activities within one function, like payroll and others became evident when functional boundaries were crossed (for example between HR and Finance). For me the idea of enterprise alignment is for an organisation to breakdown its traditional stovepipes and align its activities throughout. In today's enterprise, IT is uniquely positioned to see these disconnects as it touches all (or nearly all) aspects of the business. I see concepts like Enterprise Architecture and Service Oriented Architecture as well as technology like Business Process Automation having the potential to bring-out the disconnects and forming a key part of the organisation's journey through the continuous improvement process. The question is how IT's role in the journey will be perceived by the organisation? Will it be as a partner and enabler? I think that may be what IT-Business Alignment is striving towards.