Enterprise Abstraction

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.

Packaging is the value key

Nicholas Carr points out a presentation by Spence Wang that argues that the ends of the value chain -- content supply and content distribution are oversupplied, and that the real value in information is in the packaging.

Value, as a result, is migrating to the centre of the value chain, where content aggregation and branding take place.

This rings true in the library world, where we are seeking to discover a new purpose in the electronic age, where possession of physical material and making it available are no longer a differentiating service in the world of electronic content.

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.

SOA and the portal

I like this article from CIO magazine by Christopher Koch entitled The Starting Point for SOA.  Sometimes in all the hustle and bustle of getting things done, communicating, pontificating, and generally pursuing EA and SOA, we forget the most important thing -- the why?  Not the, it's going to save time and money why -- those are givens.  The what will this mean to us and our clients why.

We've spent a lot of time recently trying to explain SOA and the implications on our business.  I understand the opinion of some that you need not explain services and SOA to beyond IT, but in my humble opinion, that's simply hogwash.  If you believe, as I do, that EA is just as much about the business as it is about technology, then you must equally communicate on both sides.  Not necessarily about the same things of course.

This, we've recently been attempting to describe SOA as a set of layers to the business stakeholders in my organization.  We're attempting to describe the new paradigm as a stack, with "Offerings" at the top, "services" in the middle, and "products" (content/deliverables/data... this works reasonably well in most cases for a library) at the bottom. 

The take away messages being:  Services (and orchestrations of services) can be used and reused in many offerings.  We no longer want to build a silo through all three of these layers (offer, service, product), we want the bottom layers to be used amongst many offerings.  This is efficient, this will , partially, enable a nimble and flexible enterprise with good alignment between IT and business desires.

The business value of EA only becomes truly clear (beyond simply reducing costs in the IT infrastructure) when you begin to think of SOA as a strategy for implementing EA. Then the architecture effort has a built-in business goal: create an architecture designed to deliver services to the business in terms it can understand. Simply put, it's the first technical concept I've seen in ten years that actually drives alignment between IT and the business.

We've been reasonably successful in conveying previously the value of EA to the enterprise... and using the description above, SOA.  Much of the discussion at this point has be fairly abstract though, and this causes problems.

The article points out an interesting means to describe more of the "why" to the business. The portal returns.  When I started in this business (as a web developer) web portals were just finishing their reign.  Yahoo was dying off as the go-to place for the web, search engines were rising.  Google was a novelty with it's nifty "I'm feeling lucky" feature.  But the desire, at least in the library/information sector has always been to have a targeted vertical information portal specific to the needs of a particular group.  What has been lacking is a reasonable and efficient means to enable the functionality of such a set of portals (e.g. offerings) until the relatively recent rise of SOA (and its parent EA).

The story that seems to be emerging across many early adopters of SOA is that the SOA begins life as a portal. Someone in IT or the business realizes that employees would be more effective if they could avoid having to dig into two or more separate systems to accomplish a task or a process. Or, it becomes clear that employees are avoiding a system because they only need a tiny piece of the functionality and the system requires that they understand much more than they need to know. The portal--whether it's tailored to a particular employee's work role or is simply a generic single interface into many different systems, jump starts the process that is behind SOA: abstraction of systems.

What is a service really, besides being a higher-level abstraction of different application and data sources in the IT infrastructure? A well-executed portal is a marvel--undisputed ease-of-use combined with clear productivity value. Everybody's happy.

Agreed.  Tentatively.

EA and SOA are business things.  We must finds ways to describe their value, and impact, to the business.

SOA and communication with the business

I recently came across an article in CIO magazine entitled The Truth about SOA where they raise the question of communicating with the business about SOA.  The answer they provide is:  don't.

Q: SOA is a technology architecture. How do you make a business case for a new technology architecture?

A: You don't. "Don't talk to the business about SOA because the business doesn't care," says Forrester Research analyst Randy Heffner. The business's interest in SOA extends only as far as it cuts the cost of applications and gets them running faster. But simply rewriting code in the form of a service doesn't deliver those kinds of benefits. To start down the road to building an SOA, there needs to be multiple redundant IT applications that can be consolidated into a single service, or the possibility for multiple areas of the business to use a single service.

I couldn't disagree more.  Let's leave aside the apparent mixing of SOA (business planning as it relates to technology) and web services (a particular implementation technology that happens to complement SOA very nicely), and the narrow definition of SOA as specifically a technology architecture.

You must communicate at least the broad concept of SOA, because in its implementation you're going to change the IT (and possibly) business governance structure substantially.  The business must be involved in this process, and they must understand the implications of moving from (in most cases) tightly integrated silo applications and infrastructure to an SOA environment with all its advantages, and disadvantages.

One of the disadvantages are the potential implications of change and change management.  Someone needs to be responsible for these services, and to ensure that changes and impacts within the business are met.  The must ensure the service levels, extensions to the service, and predict and plan change as the business changes. 

For the business to agree and endorse these changes they must understand some of the fundamentals.  In particular, in my organization, the difference between the presentation (offering) layer, the service layer(s).  For most businesses used to running applications in silos and managing the silo from top to bottom (as a "product") this likely implies a major change -- or at least a consideration -- in the way the business, in addition to the technology, is governed.

Richard just posted on SOA Service Ownership, and some of the specific issues we're having with regard to SOA service governance.

As in most business/technology communication efforts one of the primary issues has been coming up with terms and definitions that we can all agree upon amongst the business and technology folk -- and those of us stuck between.  We've just recently come to a consensus on some of the key terms in my organization.  Perhaps I'll post some of these terms and definitions once they're a little more stable.

Akerman reviews The Long Tail

Colleague and wise fellow Richard Akerman reviews The Long Tail (previously mentioned here) in the August 3, 2006 issue of Nature.

Extended information on the topic and review is available on Richard's blog.

Gratz Richard.

Transitional Architecture

An interesting article from IEEE's IT Professional journal entitled ENTERPRISE ARCHITECTURE - Transitional Architectures for Enterprise Evolution by Murat Erder and Pierre Pureur.

The article describes transitional architectures, and introduces the idea of change in architecture avoiding the sometimes difficult direct from current to the "to be" architecture leap.  They propose what they call a prescriptive approach using a series of achievable application plateaus and architecture waves that help to ensure the achievement of business value with each transition  towards the to be architecture, and avoiding being in a constant state of transition. 

Basically, a series of architectural rest stops on the path to the final destination.

In this article, we offer our version of the prescriptive approach:  Why not briefly document the current state of the architecture, define the desired state at the conceptual level,and finally define transitional architectures on the way to reaching that goal? In other words, we introduce the idea of change within the architecture process.By following this approach,you will quickly learn which areas you need to focus on before moving forward with the architecture models and blueprints. Our method also yields several important benefits,including a focus on delivering architecture features that matter most to the business; effective risk mitigation, expectation management, and requirements traceability; and lower costs.

The article is very readable, and may be of interest to developers, designers and business analysts as well.

ITIL

In an interview with Government Computer News (GCN), Malcolm Fry was asked to compare ITIL (Information Technology Infrastructure Library) with Enterprise architecture:

To my mind, ITIL is, to some degree, enterprise architecture. I don’t see a reason [why], when you have six different service desks in an organization, you can’t have one process that they all follow and one database that they all put their incidents into.

My experience with ITIL is quite limited, but based on my understanding, it seems much more concerned with change management and ongoing processes as opposed to EA's focus on business driven, strategic, target state realization.  EA is, with all due respect, is a bit more involved than 'recording incidents' in a common repository.

That said, I'm sure that both practices have their place, and many organizations could benefit from either or both.

EA is not rocket science

I'm always looking for simple definitions of enterprise architecture.  A reasonable explanation popped up in my Google alerts feed this evening, offered by Daniel Manoli of Computerworld: 

Some areas of networking, such as satellite communications, actually involve rocket science. Building an enterprise architecture, however, is not rocket science. Its goal is to create a unified IT environment of standardised hardware and software systems across an entity, with tight links to the business side of the organisation....

With an enterprise architecture, a company creates a map of its IT assets and business processes, and a set of governing principles that support the business strategy and how it can be expressed through IT. The enterprise architecture specifies equipment, protocol and interface standards; IT strategies; projects needed to bring about the architecture and achieve the target state, and a development/deployment plan.

He adds some sage advice that I'll second:  "The key to successful EA is to keep it simple, stupid".

Development capacity for improvement

Nick Malik brings up a good point regarding the need to have extra - IT driven - capacity to apply purely to the task of simplifying and reducing the complexity and maintenance of systems.  In my experience, nature abhors a vacuum, and it's particularly difficult to have a full team dedicated to reducing complexity, even if you could justify the expense by having the team pay for itself through reduction of costs.

I think it would be particularly important in the establishment of such a team to ensure that it was driven by it's mandate to reduce complexity, and to ensure savings over the long term.  I agree that it would be best to be IT driven, and not driven (directly) by the ongoing business concerns.