Song of Deborah

No more EA

I was very bored with writing about EA - the challanges and the people they never change. SO I have changed the name of my blog and I am going to continue to do something I luv and write poetry. Bear with me and hopefully I can become a mature blogging with posts full of witty things.

Departed Ones

I think of you often

The soul by my side

Wise smile, wise words

My children are a reflection

Echo only

I wish for you here in flesh

Once more

But your guidance is seen

In the choices I make

The future you guide me toward

The life I am destined

Poem: A Balancing Act

Work or time, time or work?

Our world demands a choice,

For our fathers work was first,

Our mothers chose time.

What do we offer our children?

A home bereft of presence

With a financial calm

Or a home bolstered with essence

Where the post brings worry

Can we break this cycle?

And be the generation that wins the battle.

No to my shame, I think not.

A love poem

A gentle respectful love

Descends upon us now

Soft, warm and enveloping

Our passion has been sated

Our fervour calmed

This is now no longer new

This is forever

On the edge of our senses

The keys to unlock the passion

Easily ignited fervour

But preferring this comfortable gentle love

Nothing on EA today - a bushfire poem instead

Our hearts and minds are singed

With vivid remembering

Still fresh our grief

The loss of beauty and life 

The vision of raging fires, fierce and fast

The blackened wilderness

But the agony recedes

As renewing rain falls

Hope is rekindled in giving and song

Forward we move to build

Reinvigorating the nation’s souls

In small steps, small victories

Business Architecture Blurb

I believe that for every strategy you want to execute via EA planning you need all the BITS – business, information technology and solution architecture. Without the business architecture you are just doing IT architecture and risk technology for technology’s sake implementations. A well-defined business architecture is a prerequisite for developing a successful EA future state and defines how the business moves in response to strategic change. It also provides both the business and IT organisation with a better understanding of the business designs for the future that the technology must support.

 

I agree that as a profession EA struggles with the development of this critical piece (including most of the various frameworks and practitioners). Often this is due to a lack of understanding of the business, its relationship to IT strategic change and an inability to break down the perceived vastness of the business architecture into smaller, more easily delivered elements beyond process models. Most enterprise architects manage the technology architecture viewpoint by breaking it down into smaller pieces that enable them to understand, develop and manage the elements more effectively. Due to my time at Meta Group/Gartner, I think of the technology architecture elements as components, domains, patterns and services. Yet discussions of the business architecture treat business architecture as a complete entity, a whole unbreakable thing or small pieces of process (often viewed through a set of application goggles on (i.e. UML) rather than analysed with pure business understanding). These perspectives make it too large and complex to comprehend, let alone to start to develop in a just-enough-just-in-time approach or limit understanding of all the aspects that the business (not IT) needs to change.

 

To further complicate matters, many constituencies that impact the business architecture are often isolated from the EA team (as you discuss in your breeds of business architects Steve). Many other focus areas or people that act in the business architecture arena: business analysts, business process professionals, business managers, integration architects, risk and compliance professionals, HR professionals, etc. This is a considerably large group of players all trying to develop and manage elements of the business architecture and often isolated from each other.

 

I like to think of business architecture like I do the technical architecture as:

• Components (bricks): define individual business processes (these may be broken down into sub-processes or tasks), people, business rules and assets. The level of detail will vary from org to org.
• Domains: group business process, people and assets that reflect functional view, business units, roles, geography, and organisational structure.
• Patterns: organise processes, people and assets into groups that reflect an end-to-end perspective: i.e. business operations, product lines, business events, organisational design, and business activity.
• Services: represent a set of processes, people and assets that are delivered as a single unit and reused in this exact format every time. For example, "create new employee" adds a person to payroll, phone lists, and security; assigns a role and places it within a functional structure; aligns performance management; and so on. These may relate to business events, goals and objectives, business activity, geography, and roles. Sets of services are used for fiscal management, human capital management and performance management.

(See Gartner research G00146461 Business Architecture Viewpoint: A Framework of

Patterns, Services, Domains and Components – this is archived now and has been replaced by research by Betsy Burton but it is still my view)

 

I have also seen people use Zachman very successfully to deliver business architecture – one client organised it this way – they relied heavily on the Zachman Framework for the managing constructs to the business architecture artefacts. The work products are itemised in a typical Zachman fashion:

• The how — business process model

• The why — business motivation model

• The what — information model

• The when — business event model

• The where — locations model

• The who — organisation and roles model

• The integration of all the above in a relationship model

 

I think TOGAF is off the mark with its use of UML and basically limiting itself to process models – you need more that that to describe how the business operates. FEA CRM takes a functional view – purely demonstrating what key business capabilities delivered by government.

 

Without business architecture you do not see a complete or holistic view of where change is required to execute strategy and risk filling holes with technology when it may be unnecessary. IT is just part of the operating fabric of the business and in modern organisations EA without comprehensive business architecture will become obsolete.

What does the plan look like?

Last post I mentioned that I had developed a plan using these 7 key areas:

1.      Core EA Deliverables

2.      Communications Plan

3.      Current and Target Architecture

4.      IT Asset Portfolio

5.      Model and Diagramming Taxonomy

6.      EA Roles and Responsibilities

7.      EA Program Methodology

Let me briefly explain what the plan entailed for each area.

Core EA Deliverables

This is really about revamping the set of architectural artefacts that the EA team provide to their customers. Their current intranet site is out of day=te and much of the information is stored in share drives and peoples heads. This is not good enough. What I plan to do is:

1)      review what existing deliverables they have

2)      align them to their key stakeholders needs

3)      redevelop those that are not aligned

4)      identify any gaps

5)      fill those gaps

Communications Plan

This is about selling EA – getting a consistent message about what it is and what the team can do for the organisation (don’t think we will get to measurement just yet), communicating better (see above) and planning to keep the artefacts current and valid.

Current and Target Architecture

Wow this is a biggy – especially as they are planning for FY 09/10 – 11/12 right now and need future state architecture info. What this entails is defining the key domains across the BITS (business, information, technology and solution architecture), identifying which are critical to the business plan – do those first and then completing 1 page views for the future and current states.

It is a long weekend and I am off home – more in the last four next week.

The 10 Week Plan - Getting EA Back on Track

I finally finished the EA Optimisation Plan today – I focussed on how to get an ailing EA program back on track and focused on delivering value. Remember I believe in the Gartner definition for EA:

Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution.

The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment.

Enterprise architects compose holistic solutions that address the business challenges of the enterprise and support the governance needed to implement them.

I have grouped the tasks into seven key areas:

• Core EA Deliverables
• Communications Plan
• Current and Target Architecture
• IT Asset Portfolio
• Model and Diagramming Taxonomy
• EA Roles and Responsibilities
• EA Program Methodology

More to come on these!

What is an EA Deliverable and How Do You Make The Palitable?

One of the biggest challenges faced by this EA team is – what is our set of deliverables? I am sure this team is not alone in this challenge.

Finding an appropriate set of deliverables can be a crippling challenge for many EA teams which why they resort to filling every cell in Zachman. My first question is when giver this challenge is always – “who are your customers?”

Once an EA team can define who are their customer then they can start to tailor theor deliverables to meet the needs of the various customer groups. Here are a few that come to mind:

1. Executive management
   1. Conceptual architecture diagrams showing in 1 page views future state versus current state. Try not to product large word documents of complex detailed diagrams
   2. Analysis of strategic intent – what does the strategy really mean – break it down to that next level so that planners in your organisation can begin to understand and flesh out the detail. The exec need to ratify this
2. IT management
   1. This is a tougher audience and I think maybe their primary deliverables is the current state architecture information – they need to own and manage this information so it must be designed in a way that makes this easy – think about portfolio management as a method for doing this
   2. IT standards and guidelines – the classic foundation pice for most EA teams – reference architectures.
3. Project teams
   1. This where you start to think about the more detailed deliverables that assist the execution of the EA future state by the projects.
   2. Logical level design documents
   3. Technical architecture domains, patterns, services – future state only
   4. Solution architecture documents – often developed in concert with the solution architects in the project teams

There will be many more “customers” with their own sets of deliverables – who would you say are your EA’s primary customers?