Practicing Enterprise Architecture

Closing the Innovation Gap (My Last Post Here)

2011-04-21T07:39:00.000-07:00

Before I Start

You may have noticed that this blog’s subject matter covers EA practices, challenges and strategy but does not say much about technology. While this has been important over the past few years to move EA out of a pure-play technologist role, I think it is time for a change.

Writing about emerging technology and innovation is what my new employer, Forrester Research, hired me to do for its EA clients. I think it is both a good fit for me and for the practice in general. I’ll say more about my research coverage and why I think this at the end of this post. For now, please read on as I depart this URL with a challenge that we must rise to now - closing the innovation gap.

While We Weren’t Looking, a Gap Opened

In our scramble to meet the demands of two opposing forces, we have allowed an innovation gap to arise in our organizations. The forces:

Answering the business’ call for change. Change is a byproduct of business competition in a free market, and we must foster it. Those who adapt to changing conditions and most quickly seize new opportunities will prosper. My colleague Henry Peyret just published some great research on business agility that examines this very issue in more depth.

Taming the current state and managing technology TCO. Our current state is generally too expensive and too complex for the value delivered. As EAs, we spend much of our time dealing with this.

These two forces appear opposed - one calls us to the new and innovative, while the other drives us to limit, standardize and simplify, often to the detriment of innovation. These forces are not naturally opposed, but our approach to solving the dilemma makes often makes them so.

What is this gap? How do we balance our approach and close it?

The Gap — Not Fast or Cheap Enough

Simply put, we are not delivering innovation and new technology fast and cheaply enough, forcing the business to do it itself.

Shadow IT is the effect of this gap and has been the thorn in the side of in centralized IT for years. Traditional IT thinking says, “Stop the business from innovating with technology! That’s our job.”

Rather than fight, there is a better way, and getting to this better way is inevitable. The only question is, how long will it take?

How do we move from trusted utility to business technology partner? How do we both empower the business and keep systems safe and data secure? How do we get ahead of emerging technologies to help close the innovation gap? That is the subject of my research - and I invite you to collaborate with me in figuring out how to make this happen.

In concluding part 1 of this post, I am pulling a dirty trick and shameless plug for Forrester by asking that you follow me over to my first post on the Forrester site. I will pick up the conversation there, offer some ideas about how we might act to close the gap and provide a preview into some of my research.

Your readership has been important and continues to be important. Thank you again.

Brian Hopkins
Principal Analyst

Work Phone: +1 617-613-8920 | Email: bhopkins@forrester.com

The ‘Order-Deliver’ IT Model is Broken

2011-01-21T12:12:00.000-08:00

The current IT Delivery model will not support tomorrow’s competitive environment.

It simply takes too long. While the Business is “ordering” and IT is “delivering”, another more nimble competitor has pulled their business partners into the kitchen and prepared a better dish, together, in half the time.

Over the last five years, practicing EA has provided a front row seat to some serious shifts in corporate thinking driven by two factors:

Economic meltdowns that reinforced the balance sheet’s importance. Shareholder equity = Assets - Liabilities. That’s an easy formula that will not change with technology. How much equity and therefore value a company has will always be dependent on the decisions it makes about managing assets and liabilities for the greatest return. If you need an example, look no further than the housing crisis. Many of the greatest investment banks were ruined because their liabilities (shaky mortgages they helped lending institutions underwrite) far exceeded the long term asset value. This lessons still reverberates in the minds of CEOs everywhere, not just the financial sector - the business case for investment must make sense and IT is no exception.
Big, “Enterprise” solutions weigh heavy on corporate profits - now a new technology wave is coming. Since about 2000, large corporations have been investing heavily in big, enterprise systems that automate and optimize core business functions. Vendors have supported industry vertical solutions by a “mix/match/customize” approach, with lots of professional services for each dollar of software sold. These investments, funded with heavy capitalization, are now showing up as depreciation on corporate balance sheets. While companies pay off these large capital procurements, a new generation of technology is emerging that can collect a data from the environment with new sensors and process this ‘Big Data’ with next generation Business Intelligence in highly specialized, industry vertical solutions. The Cloud has emerged to allow much of the required technology to be rented in a pay-per-drink model, making large capital commitments a thing of the past.

It’s cliche, but true - the only constant thing is change. How well we adapt to it is what determines our survival.

The 80/20 Rule Applies

The 80/20 rule suggests that big, capitalized, enterprise technology investments are diminishing in importance. Most companies have made the 20% investment that gives 80% of the benefit, and investing more for diminishing returns doesn’t make sense. What does make sense? Building out process automations with new, “smart” technologies to measure, analyze, predict and react with great speed and agility. Vendors are beginning to offer highly specialized solutions that solve critical, industry specific problems and require little in terms of long term capital commitment. Add in the Cloud, with a pay-per-drink pricing model, and buyers will be able to ‘opt out’ of solutions that do not meet expectations. Things indeed will be different.

The New Order - Innovation, Agility and Accountability

If the old model is broken, what new one will emerge? Three characteristics define it:

Innovation. Innovative businesses that can adapt their thinking to the new environment will adopt emerging technology to solve “unsolvable” business problems.
Agility. Business that can experiment, fail fast and quickly redirect to the right solutions will out pace their competition.
Accountability. Good decisions must be rewarded, and good accountability means both clarity in who gets to say “yes” and then tracking and tying the results back to executive performance.

Each of these is perhaps its own separate blog, which I will save for future posts. I conclude with a thought that summarizes EAs best role in this new model - we must become the facilitator of good business decisions by 1) understanding our business and the potential of emerging technology, 2) clearly defining the impacts of both good and bad architecture decisions and 3) enabling business ownership and shared Business/IT governance of technology investment decisions.

The Essential EA Toolkit Part 4 - An Enterprise Roadmap

2011-01-16T04:58:00.000-08:00

This is the fourth and final part of my “The Essential EA Toolkit” series covering some recommended tools for Enterprise Architecture Teams. By "tools" I mean a few well-executed deliverables or processes that contribute enormous value to the enterprise. These are not technologies; they can be developed using typical office productivity technology and perhaps a collaboration application such as SharePoint. Before I start, here are links to the first three:

In conclusion, the final tool is the Enterprise Roadmap...

An Enterprise Roadmap is the Linchpin for Transformation

The economic collapses of the 2000’s left a profound effect on businesses that includes a revaluation of how resources are spent on technology. As a result, IT budgets are lean, there is renewed focus on realistic business cases for investment, and CIOs recognize old ways of doing business will not work in the new economy. A mandate to transform is the legacy of these trying times.

Achieving a transformed ‘future state’ requires a tool to guide and govern day-to-day resource investment decisions - the Enterprise Roadmap. Roadmaps both compel us to towards the future and provide a basis for evaluating enterprise investment decisions required to get there. They are fast becoming necessary, and organizations without one will soon be left at a competitive disadvantage.

Good Roadmaps Have four Common elements

Besides a time-phased plan of action, good roadmaps have four other common elements:

Blueprints & Business Scenarios define a compelling future state. In order to be successful Roadmaps must compel us to the future state - no organization will maintain the discipline required for success without these. ‘Blueprints’ form the basis of our vision, and are created a various levels, from business friendly ‘sketches’ to data, application and technology focused details. Business Scenarios complement Blueprints by describing the desired outcomes and identifying key people, process and technology changes required to achieve them. Blueprints and Business Scenarios cross reference each other, clearly telling the story: “If we do these things, we will get to where we want to be”.
Complexity is simplified by defining ‘Enterprise Programs’. Large organizations are guaranteed to have many needs, competing agendas and a legacy of applications, technologies and desired projects. These challenge roadmap development by adding complexity. The best Roadmaps identify a few enterprise strategic themes, then rely on ‘Enterprise Programs’ to execute the appropriate steps. The old adage, ‘if everything is important, then nothing is’ rings true - good Roadmaps clearly identify important strategic goals and focus on attaining them.
Key Performance Indicators measure success and prevent failure. Many external factors can influence business performance, therefore non-financial Key Performance Indicators (KPIs) are necessary. The best roadmaps assign non-redundant KPI goals to each Enterprise Program. For example, a ‘Common View of the Customer’ program should set data quality measures to assess confidence that there is a single view of every customer. Other programs should not also target customer data quality as a primary benefit. Programs must take early action when desired outcomes will not be reached. History is littered with failed efforts that recognized a different approach was required too late. Close monitoring of outcomes is a must to prevent Roadmap’s from derailing.
A high-level financial model provides insight and direction. A high-level financial model is a final important component of a good Roadmap. Executives must be able to see quantified financial impacts in order to make large-scale investment decisions that roadmaps often require. The best models define program and project benefits to KPIs, which themselves are linked to expected financial performance; results are recorded over time using accounting standards to generate cash flow and expense projections. Project and program classifications allow analysis of cost and benefit by strategy, capability, process and line of business. Classification of project cost and benefit yields insight, answering the question, “are we investing in the right things to achieve what we want?”

Developing a Roadmap is Easy, The Hard Part is Successful Execution

Developing an Enterprise Roadmap is a difficult task, requiring a board-level mandate to transform and a significant shift in culture. Many organizations struggle with the necessary mindset as well as the format, employing management consultants, facilitated workshops and multiple attempts. Because of the sheer effort to produce one, businesses can easily over self-congratulate before any results have been recognized. The bottom line is that a Roadmap unexecuted or failed is as bad as no Roadmap at all because of the time wasted and the political fallout of such a failure - stay focused and take the following steps:

Maintain business ownership; establish accountability and governance. Any successful Road-mapping effort required business ownership to complete; however fight the temptation to execution over to IT. This must not happen. Enterprise Roadmaps are tools to make business decisions about business and technology transformation. Keeping the business in possession of the roadmap requires enterprise accountability at the highest levels of any organization. Establishing clear decisions making authority and assigning results to executive performance requires an enterprise governance mechanism - this may be centralized or distributed with clear lines of responsibility. A Roadmap Execution Office, either as a single entity or virtual office, will be helpful.
Implement a Benefits Realization capability. Successful execution of a roadmap requires methodical, consistent measurement of KPIs and translation of those into financial measurements when appropriate. Often the best way to accomplish this is through a Benefits Realization capability. I say ‘capability’ because there are a mix of people, process and technology approaches that work. The commonality is that they all assign KPI to executives and programs, ensure that projects build out facilities to measure performance, and feed the results to enterprise reporting so action can be taken if expected outcomes are not achieved.
Execute disciplined information and change management. Execution of a roadmap involves collecting a lot of information about the your organization - strategies, projects, process and technology blueprints, financial and KPI projections, etc. This information will change overtime resulting in many ‘.ppts’ with different versions of the Roadmap. Besides preventing confusion as changes happen overtime, the biggest challenge is ensuring that the right information is brought forward to leadership for governance decisions. A roadmap Execution Office, proper change control processes and some technology tooling will help ensure the integrity and quality of the roadmap source data.
Exercise patience and a first-things-first attitude. Roadmaps can span varying lengths of time, but generally target three to five years. Undoubtedly, there are some ‘foundational’ things that must be done in order to achieve the desired benefits that are part of early project work, and often these efforts show little in the way of ‘hard’, bottom line impacting benefits. The existence of foundational work means that the roadmap may not show dramatic benefits over the first year or two of execution; in today’s economy, this can be very hard to abide. While roadmaps should have ‘quick hit’ projects that deliver short term benefit in an effort to partially self fund, tactical investment is not the point. Successful organizations must be committed to the end-game of the roadmap and have the discipline and patience to invest in foundational things first.

The Essential EA Toolkit Part 3 - An Architecture Governance Process

2010-10-11T12:41:00.000-07:00

The Essential EA Toolkit is a four-part blog on some recommended tools for Enterprise Architecture Teams. By "tools" I mean a few well-executed deliverables or processes that contribute enormous value to the organization (read Enterprise). These are not technologies; they require only standard office productivity software and perhaps a collaboration application such as SharePoint.

The Essential EA Toolkit (Part 1) identified the following four items:

A Business Capability Model (see Part 1)
A Standards Repository based on a Reference Architecture (see Part 2)
An Architecture Governance Process
A Strategic Blue Print and an Enterprise Roadmap.

This post examines the third - an Architecture Governance Process. In last week's posting I presented a definition of IT Governance:

"Specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT."
- Weill, P. & Ross, J. W., 2004, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results", Harvard Business School Press, Boston.

Governance is an essential function of Enterprise Architecture. An Architecture Governance Process is the set of activities an organization executes to ensure that decisions are made and accountability is enforced during the execution of it's architecture strategy. An effective EA Governance process institutionalizes decision making and ensures accountability for decisions related to this. The Enterprise Roadmap, lays out the strategy, while the standards establish the building blocks used in execution.

The extent to which this definition differs from IT Governance depends on the role of EA in the organization. For most, the term "Enterprise Architecture" still implies "Enterprise Technology Architecture", therefore EA Governance is tactical and narrowly applied to conformance checking against technology standards. In a growing number of companies, EA is gaining ground as a strategic activity and therefore EA Governance is broad and approaches or exceeds the scope of IT Governance.

Here are two examples -

Example 1 - Tactical EA: An organization has established an Architecture Standards Repository and filled it with content specifying technology product configuration, application development and data management standards. The governance process specifies how projects and infrastructure services are checked for conformance, how they are approved, who gets to make exceptions decisions and under what conditions.

Example 2 - Strategic EA: An organization has just completed delivery of an Enterprise Roadmap in partnership with the business. The roadmap lays out the technology investment strategy for the next 18 months, identifying the programs and projects the business intends to invest in and how those investments build out the enterprise's architecture.

Governance process establish the checks, accountability and decision points to ensure that investment dollars execute against this roadmap and the future architecture is achieved. How will the organization identify deviations? How will they be handled? Who approves these? How will changes be communicated? Who is accountable if changes lead the organization astray?
Both examples are valid approaches and depend on how an organization defines Enterprise Architecture; it is therefore critically important to effective governance that an organization have a definition.

Here are three components of effective EA Governance. The first two are commonly recognized as being part of "EA", while the third is an EA function in a strategic sense but is not solely owned and executed by traditional EA teams.

An Architecture Review Process
A Standards Management Process
A Roadmap Management Process

An Architecture Review Process -

This process establishes periodic reviews of solutions at various points in the technology delivery lifecycle and proposes changes to the body of architecture standards. It is tactically focused; with the objective of ensuring conformance to strategy and standards, identifying exceptions, and documenting issues with enterprise impacts.

Most mature architecture organizations have some form of architecture review, however some overlook a fundamental benefit - review provides a chance to educate and seek consensus.
In these organizations, review is conducted purely by a team of "architects" who scrutinize the documentation and pass or fail it via an Architecture Review Board (ARB). This practice, while it can be effective, promotes an ivory tower perception and estabishes an "us/them" relationship between architects and the rest of IT.

A better practice is to have broadly attended Architecture Review Meetings to communicate, promote understanding of and answer questions about a proposed architecture. Invite managers and working level technologists from infrastructure, development, security, testing, and of course architecture. Out of the meetings document issues such as potential deviations from or gaps in standards; also identify enterprise dependencies.

With plans to resolve issues in place, architecture approval can then be sought by an ARB consisting of executives from the various IT departments - not just architecture. Since these executives and their subordinates were invited to the Architecture Review Meetings, there is no need to rehash details of at ARB. Instead, only the issues are discussed and approval is sought to move forward if items remain unresolved or exceptions exist.

In addition to being more collaborative, this approach promotes ownership of the architecture broadly across the IT organization and establishes clear accountability for proceeding via an executive-level ARB. In addition, it improves participation in the process because people's time is more effectively used. Working technologists can attend the review meetings, then brief their executives on issues at the ARB prior to vote.

Since a primary purpose of the Architecture Review Process for most technology-oriented EA practices is evaluation of solutions against enterprise standards, the next governance process manages those standards.

A Standards Management Process -

The Standards Management Process establishes change control over architecture standards (see The Essential EA Toolkit Part 2 - A Reference Architecture and Standards Repository). It defines how an organization tracks deficiencies and gaps in its body of enterprise standards and methodically works toward improvement.

While the Architecture Review Process is about review of solutions and changes in the standards; the Standards Management Process is about controlling the change process and communicating the impacts.

A good standards management process -

Identifies and documents enterprise standards that need or present an opportunity for improvement.
Assigns accountability and responsibility for improving the standards.
Takes input from and proposes changes to technology and business components of an Enterprise Roadmap.
Measures and reports against changes to determine effectiveness.

A Roadmap Management Process -

A final element of effective EA Governance is managing change against the Enterprise Roadmap. I consider this an EA process even though it is not entirely owned and executed by the EA group (depending on the organization's definition of EA.) In many IT shops, management against strategic assets such as a roadmap is the function of a business strategy and planning group. This team is, in a broad sense, part of the organization's EA function, whether so named or not.

I tweeted recently, "Having a roadmap is only half the battle. Executing to it and managing change against it is equally as tough!" I was surprise at the number of retweets, indicating that this is on people's minds.

An effective roadmap management process has several elements. First, a clear definition of what the roadmap is and is not is essential; creating this definition can be tough. Is the roadmap a PowerPoint presentation? Is it the underlying data about the proposed investments and technology landscape? Is it statements about strategy and desired outcomes made in other communications?

Once the contents of the roadmap have been defined, components that will be controlled, Rules about how changes are made and who approves them must be clearly documented. The Roadmap Management Process helps set expectations, promoting continued business and IT partnership through transparency. Without it, the benefits of the roadmap quickly vanish as uncontrolled changes make the roadmap irrelevant and governance impossible.

In conclusion, governance is an essential EA function. It ensures strategic alignment of projects and assists in achieving technology goals by enforcing and managing exceptions to standards. Two essential elements of Architecture Governance that are traditionally viewed as EA functions are an Architecture Review and a Standards Management Processes. Roadmap Management is a crucial part of governance as well. I assert that developing and managing the roadmap is an Enterprise Architecture function, even though it may be owned and executed outside of the traditional EA team, hopefully in partnership with IT strategy/planning and the business.

Next I will conclude this series with the final, and in my opinion, most important tool - an Enterprise Blueprint and Roadmap.

Cloudsourcing

2010-09-08T04:18:00.000-07:00

Cloudsourcing is the combination of Cloud Computing and Outsourcing. Individually, they are impacting how Enterprise Architecture is practiced; together they form a driving force for evolution of the practice.

The lexicon of Cloud Computing is rapidly evolving. Perhaps the most significant, yet nascent Cloud trend is the rise of Platform as a Service (PaaS). While traditional cloud offerings focus on infrastructure or basic office applications in The Cloud, PaaS vendors such as Salesforce, Amazon and Google offer a Cloud-based development and hosting platform. While these vary significantly according to purpose, they all feature tools that can rapidly develop, deploy and manage Cloud applications from anywhere via the Internet with a minimum of traditional coding. Consider the impact of this trend.

As enterprises move larger portions of their application stack to PaaS, they become less concerned about managing specific technology products and hardware environments because technology is now abstracted from the code and configuration. They also become less obsessed with the number of applications as a driver of Total Cost of Ownership (TCO), since cost is not based on traditional hardware, software and development maintenance costs.

Offshoring is not new. Many organizations are on their second round of it. Even though most EAs have experience with offshore outsourcing, many EA practices have not adapted to it. The drivers here are a time zone and language barrier that increase the importance of institutional knowledge and documented standards.

Considering these, Cloudsourcing has the following impacts on how we practice EA.

It shifts the focus towards the business and away from technology.
It elevates the importance of application fungibility and decreases that of complexity as the primary TCO driver.
It increases the importance of documentation and standards.
It increases the importance of integration through services.

Cloudsourcing shifts the focus of EA towards the business

Many EA practices are still pure technology plays, focusing strategies and standards for the efficient management of technology and the delivery of enterprise-classapplications.
In a fully Cloudsourced enterprise, IT neither owns the hardware, selects technologies or manages the human resourced needed. EA practices that remain focused on technology will have less and less to do; practices that shift toward the business will be more free to add value by considering how best to design the enterprise for success, where technology plays a part but it not the focus.

Cloudsourcing elevates the importance of application fungibility as the primary TCO driver

Fungibility is "the property of a good or a commodity whose individual units are capable of mutual substitution." - Wikipedia.

When applied to IT, it refers to the ability of an application to move in and out of technology systems or processes and is a major concern of organizations considering the move to cloud applications. Because it is early stage, no standards exist for Cloud applications, therefore moving an application from one platform to another is impossible without a complete rewrite.
As a counter example, the J2EE suite of programming standards ensures that an application can port from one J2EE-compliant platform to another. No such standard exist for Cloud Applications. The concern is for early Cloud adopters is vendor lock-in; as the ultimate pricing models for Cloud services have not stabilized - nobody is sure exactly what the TCO will be.
Considered in the context of an outsourced environment, fungible applications can be more easily maintained by various off shore providers because they are designed in a standard fashion.

Cloudsourcing increases the importance of documentation and standards

Cloudsourcing means that off-shore resources are both providing infrastructure services and developing applications on a Cloud Platform. Realities of outsourcing are language and time zone barriers. While infrastructure services are likely to have help desk operations on US time, application development teams are likely not. Standardization of IT delivery, management and architecture processes through documentation will become increasingly important tools to help overcome these obstacles.

Documentation and standards is also important for Cloud applications as they improve fungibility.

Cloudsourcing increases the importance of integration through services

A challenge for PaaS applications is security for an enterprise's data assets. Most organizations are not, and may never be comfortable with vital corporate data living in the Cloud.
For this reason, an important component of any PaaS strategy is integration with data managed through indigenous technology. Cloud vendors offer solutions claiming conformance with web standards, however many choices remain. Enterprises that have a mature SOA will be at an advantage in easily integrating Cloud applications into their environment while retaining vital data in-house.

Take together, what do these mean for Enterprise Architecture and the organizations that rely on the practice? In a fully Cloudsourced organization of the future, technology-focused EA teams may go away as their primary mission of ensuring the integrity and cost effectiveness of the technology environment will diminish in importance. In order to be effective, focus must shift to business strategy and governance, ensuring applications meet requirements and data is both available and secure.

Application architecture no longer focuses non-functional requirements for performance as these are guaranteed by Cloud Providers or specified in outsourcing contracts. Rather, it must focus on the fungibility of application components and of applications as a whole; evaluating TCO in a totally new cost model.

The net effect of Cloudsourcing - a brave new world.

EA teams that focus on business architecture, strategy and governance will be increasingly important as organizations will continue to grapple with the question, "How do I best expend resources to further the organizations goals". We EAs must focus on answering that question, regardless of the technology.

Evolution Was Bad for Neanderthals (Redux)

2010-08-26T04:16:00.000-07:00

If you were a Neanderthal, evolution was bad; at least the dinosaurs left birds. Humans emerged and you were no longer relevant - you and your buds left a lot of nice bones for us to dig up. When technology professionals of the future dig up our bones what will they find? Ancestors or Neanderthals?

In a recent discussion on Linked In's Enterprise Architecture Community, a pundit reminded us of a sobering Gartner prediction - that something like 40% or 60% of Enterprise Architecture groups in organizations will go away in the coming years because they have failed to establish their value. James McGovern recently tweeted, "mcgoverntheory - The practice of enterprise architecture disappears from another Fortune enterprise. Is this an increasing trend?"

Everybody in the blogosphere likes to write about the definition of EA - I've done it a few times myself and probably will again (see Real Architects Don't Wear Ties andWho's On First). That's not a bad thing, but what gets me is the endless wrangling over that definition that always seems to ensue. Check out any Enterprise Architecture group discussion board on Linked In, they are chock-full of long debates on this subject. These are exemplary of my point - we can't seem to get past ourselves to define a common lexicon for what we do and a "Body of Knowledge" that standardizes it.

Alternatively, I can work with a project manager who is PMP certified and have a good idea of what the she knows and how she will go about her job. This makes it very easy to know when I need a PM and what to expect when I do. I am not suggesting that we reduce our craft to a rote set of processes with standard deliverables, but I am saying that some standardization would go a long way towards helping the organizations who hire us understand what it is we do and how we add value.

If we must expend energy debating what EA is, then let us do it in a forum were we can reach agreement; if we cannot agree the perhaps we should turn that energy towards adding value to the organizations we work for. In my view, here is how the practice of can do just that:

Provide a center of enterprise thinkers who consider the good of the long term whole - organizations need this to balance the short term, "what's in it for me" attitudes that drive the results many companies and consistently produce mediocre results. EAs balance this, challenging companies to be better than they are.
Document the future state of our organizations holographically vice photographically (thanks Tom Graves for coining this idea). By this I mean provide a "three-dimensional" picture of the enterprise that acknowledges multiple perspectives and an evolutionary nature instead of a single perspective at a point in time.
Cut through the noise to laser focus on the few key issues and organizational changes that can add the most value to our organizations. There is typically a tremendous amount of activity in large IT shops; as EAs we must use our experience to sift through this noise and listen to our Spidey-sense when we identify something as really important; then go after it.
Continually broaden our perspectives. Most of use became EAs because we are "jacks-of-all-trades"; this led to a breadth of experience and a holistic view of things that pulled us into the practice. Once there, however, it is still easy to become pigeonholed. If you are a technologist, seek to work on business things and vice versa. The more broad and diverse we are, the better we will be at contributing that which makes us valuable to begin with.

For those of you who have been following my blog for a while, you may recognize this as a rewrite of a November 2009 post. After observing the craft of EA during this period, my hopes are up that we are evolving. In The Practice I cover three trends that indicate evolution - smaller EA teams, more emphasis on strategy, process and governance and last, the external influences of managed services and outsourcing on how we do things.

In conclusion, I encourage readers who consider themselves architects to continue to push towards the enterprise. I think we are on the right evolutionary branch in that the potential of EA to benefit organizations that diligently execute it is significant, however time will tell.

The Essential EA Toolkit Part 2 - A Reference Architecture and Standards Repository

2010-08-13T08:35:00.000-07:00

The Essential EA Toolkit is a four-part blog on some recommended “tools” for Enterprise Architecture Teams. By “tools” I mean a few well-executed deliverables or processes that contribute enormous value to an organization. These are not technology focused, requiring only standard office productivity software and perhaps a collaboration application such as SharePoint.

The Essential EA Toolkit (Part 1) identified the following four items:

A Business Capability Model
A Standards Repository based on a Reference Architecture
An Architecture Governance Process
A Strategic Blue Print and an Enterprise Roadmap

This post examines the second, which is actually two items that work together - a Reference Architecture and a Standards Repository. These tools facilitate both delivery of architecture and governance against it – both common functions of an EA Team.

A Reference Architecture

A Reference Architecture is an anchor for other architecture deliverables; the Business Capability model discussed in Part 1 is an example. If you read that post you already have a feel for what one can do.

To be more precise –

A Reference Architecture is one or more abstract models describing, organizing and showing the desired relationships between the capabilities of an organization from business, information systems and technical view points.

Physically, a Reference Architecture is a combination of models in the various Architecture Domains combined in such a way that they are all consistent, reflect organizational attitudes and are easily understood by the appropriate audiences.

The reference models create a common understanding of what an enterprise “can do” in terms of business, data, applications and technology; allowing EAs to connect the dots. This is not a new concept, there is a lot of reference architecture information available; the Common Reference Architecture or CORA model is one of my favorites:

The model provides a way to conceptualize and anchor on the components of an architecture so that “everyone sings off the same sheet of music”. Note that there are a limitless number of ways to model a Reference Architecture. Each model must be suited to a purpose.

The CORA model is really useful as a reference for creating Information System views of architecture; by that I mean descriptions that focus on high level data and application integration capabilities. The “top” of the model is light on business items (the Business Capability Model discussed in Part 1 is better suited for anchoring business architecture, for example) and the “bottom” is light on technology infrastructure (servers, storage, networking, etc.).

As an alternative to CORA, The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight from IBM provides an “information services” based Reference Architecture that focuses on describing architectures as composed of information services.

Reference Architectures are useful in two ways. First, and most obviously, its elements serve as a basis for other architecture deliverables. For example, one can create an Integration view of a solution architecture that includes specifics on how data flows between components via messaging protocols. The components in this application architecture model are lifted directly from or refer back to a Reference Architecture model. Using the same model, the Technology Architecture team can create an architecture describing how messaging services are implemented through various technology components. Since both use the same Reference Architecture, the application and infrastructure architects have a common basis for understanding the design.

Finally, Reference Architectures are a great way to identify and classify standards.

Standards and a Repository for Them

Architecture Standards are necessary in order for decision makers to assess a potential investment or technology alternatives and make the right call. A Standards Repository stores the Standards such that they are organized logically and available for governance.

The term standard in many organizations is used ambiguously leading to churn. For example, I’ve been in meetings where the words, “that’s not our standard for ______” have been used as an argument against a solution’s approach. When questioned further, the objecting architect was only able to identify the standard based on the recollection of a PowerPoint – yet nobody seems to be able to produce the deck or any documentation that the deck was approved as the standard. Another common issue with standards is they tend to be “tribal knowledge”…the statement, “everybody knows that’s not our standard” is another rationale that I’ve heard in frequently.

My recommendation is to precisely define what a Standard is and what types your organization needs; then write them down and put them in a repository for all to access. Lastly, govern to these and only these.

While this is easy for me to say, it is a lot of work. Furthermore it removes power from architects since they must commit to what they will and will not govern against – in other words, I recommend adopting the position that if it’s not documented, it’s not a standard.

In order to be effective therefore, standards must be:

Typed – that is various levels of standards must be established according to types. Some common ones are technology product standards, architecture and design patterns, strategies and principals. Each of these can serve as a basis for comparison of a proposed solution or alternative, enabling better decision making at various levels.
Classified – Due to the variety and complexity of technologies available, an organization of any size is likely to have quite a few standards. A classification scheme is necessary to enable users to narrow searches; a Reference Architecture is a natural for this purpose. For example, with the CORA model, a set of principles can be written for the entire application integration stack. Strategies can be defined for each major block (Channel Access, Presentation, Composition, Integration, etc.) while Technology/Product Standards (WAS, IIS, JMS, MQ, Sharepoint, IE, etc.) and patterns can be created for each sub-block.
Stored in a repository - this is the last and most vital step. Regardless of how well typed and classified standards are, if they are not stored in a single, known location, they are much less useful. It would be like the legislature passing laws documented on napkins stuffed in their coat pockets. While many organizations use an EA tool such as System Architect to document and publish standards, this is not necessary for many organizations. We use Sharepoint and it works just fine.

In Part 3, I will discuss the third “tool” – an Architecture Governance Process, which is the essential set of activities that enable effective architecture decision making using the tools we have discussed so far.

The Essential EA Toolkit (Part 1)

2010-07-26T14:39:00.000-07:00

In order to be effective, Enterprise Architecture teams need “tools” in their toolkit, and I don’t mean technologies like System Architect or Troux. Rather, I am referring to a few deliverables that create enormous value for your business and can be realized as simple drawings, processes and existing collaboration applications.

This four part post presents for your consideration some of the more effective tools I’ve identified:

A Business Capability Model
A Standards Repository based on a Reference Architecture
An Architecture Governance Process
A Strategic Blue Print and an Enterprise Roadmap.

Tool 1 - A Business Capability Model

A recurring theme of this blog is the creation of business value through simple, easily consumed deliverables, which requires a common language in order to develop a pool of shared meaning (see Who’s On First?). The moment a team realizes that it has to be able to talk to the business but does not know how is one of the bigger “a ha” milestones in EA maturation. A Business Capability Model provides a foundation for this type of communication. It is a simple “nested boxes” diagram that represents the “capabilities” a business has or desires. Here is an example, shown with some Strategy overlays:

You may notice that much of the model looks similar to a corporate organization chart, however the model is different - it is purely based on capabilities and not company divisions or locations. It may have some boxes that correlate to corporate divisions, but some do not. The best example is “Customer Engagement”.

Since many divisions deal with customers in some form or fashion, Customer Engagement is something an Enterprise must be able to do well across organizational boundaries. When no single executive has accountability for the Capability except the CEO, getting things done at a working level becomes challenging. One solution is to assign the single accountability; however that may not always be practical.

The Business Capability Model helps align executive stakeholders when it is not by creating a set of “lenses” for describing the architecture in ways that are immediately useful to the business. Because the model is based on Capabilities, vice divisions, it drives enterprise thinking; especially in those Capabilities that are share functions with more than one department.

Continuing the Customer Engagement example, a set of “Customer Engagement” architecture deliverables can be created that clearly communicate enterprise strategy, provide a basis for cross divisional alignment and set expectations for investment.

Here are some practical uses of the model:

As implied, Architecture deliverables can be cast in terms of a Capability providing different views of the Enterprise Architecture to different stakeholders. For example, executives concerned with customer interactions, such as Marketing and Distribution, can focus on the Customer Engagement roadmap while those in Manufacturing and Purchasing may not pay as much attention. See The Quantum of Integration for more on the power of Views in architecture.
Strategy overlays, as show above, are a useful way to identify required investment. For example, the strategy to “Open Web sales channels by improved segmentation…”, show as a red line, impacts the Marketing, Distribution and Customer Engagement capabilities. Further drill down into these, specifically identifying functions that must be enabled or improved, can yield an appropriate set of IT investments focused on delivering the strategy.
Capabilities can be used to classify investments as part of a roadmap. For example, capturing a qualitative estimate of the % contribution of an investment to driving Capabilities allows analysis of corporate investment against strategy. Picture a pie chart of total investment by strategy as “gut check” tool for executives.
Applications can be analyzed by Capability in a similar fashion to process and investments. An analysis of applications and planned investments by Capability can produce useful decision aids as organizations make budget decisions.

In developing the Business Capability Model, there are a few traps to avoid:

Avoid overcomplicating the model. Shoot to have no more than 15 components and go one level deep to begin with. Since the model is used for communications to the business, ensure that it is something a business executive can look at and digest without a lot of explanation. Go for the “I get it” expression.
Ensure the business buys into the model, and preferably helps IT develop it. The model is a combination of architecture “purity” and business pragmatism. Many early attempts at such a models gave names to the boxes that no business person understood. We architects may get it, but this is not a tool for us. In my personal experience, it took three or four attempts over as many years before we landed on a model that the business accepted.

After you have a working model and are using it to effectively deliver value to the business, take next steps like decomposing the first level components into functions and defining relationships between the components according to business process that cross capability boundaries.

Next week, I’ll continue this discussion with Tool 2 - A Standards Repository and a Reference Architecture.

The Practice

2010-07-19T09:22:00.000-07:00

2008-2009 was a watershed for the EA Practice. Those that remain and thrive in the later days of the Great Recession are leaner, more business focused, delivering measurable value through strategy, governance and focus on critical interfaces between key enterprise components.

There are three trends that support this conclusion:

EA Practices are getting smaller and more focused on the business
There is more emphasis on strategy, process and governance and less on frameworks and tools
Managed services and outsourcing are driving architecture toward the lines, away from the boxes

For those who have read much of this blog, you know that a big theme is evolution of EA as a practice. In Evolution Was Bad For Neanderthals I stated that it's transform or die out. Thankfully, I think we are evolving.

EA Practices will continue to get smaller and be more focused on the business

The down turn in the economy has forced corporate America to carefully evaluate IT departments and ask, "Do I absolutely have to have this?" Let's face facts - it is hard to understand what we do; see Who's On First? and Nik's Malik's Understanding Enterprise Architecture. Businesses have retained EA teams that are perceived as being immediately valuable and jettisoned the rest.

While the signals of this are weak at present, it follows naturally that important skills for EAs are shifting toward the Business and Information layers in the Architecture domain stack because this is where a smaller EA teams can have the most impact on the company bottom line. If you are a young EA or desire to get into the profession, suggest developing the skills necessary to have a conversation with the business about process, data and technology in terms of cost, benefit, capability and risk then learn how to turn this information into simple boxes and lines that describe the future state.

There will be more emphasis on strategy, process and governance and less on frameworks and tools

In Welcome to Frameworkville and Digging to China, I state that frameworks and tools are on the path to architectural maturity but are not the path to it. My perspective comes from personal experience and talks with other EA teams - we all mistakenly thought that buying a tool or implementing a framework was the way to grow an EA capability.
Tools are complex, frameworks are abstract AND complex. Both require a recognition of the value of EA and a long term commitment to practice it a the highest levels. Considering the economically driven focus on survival, EA activities that provide immediate value to the business are better first steps towards maturity. Developing credibility as a strategic asset to the business is never a bad early step.

Effective EA teams, as they mature, will:

Focus on providing easily consumed, strategic deliverables that executives can use to make decisions about the future of the business. Less "boil the ocean" analytic exercises with dubious short term value will be tolerated. Both tools and frameworks, while good, can distract teams from producing value.
Define repeatable processes for producing EA deliverables then measure progress against these with a set of metrics. Continuously reporting progress against metrics is crucial to the survival of the EA team. It will also help drive priority decisions.
Enforce architecture standards through governance, but consider principles and strategies as higher order standards. Maturing EA teams will develop "standards" in the form of principles and strategies first to supplement detailed technical specifications. Shortly, practices will realize that these strategic governance tools are making a bigger impact that the detailed technical ones.

Managed services and outsourcing will drive architecting the lines and not the boxes

Many IT organizations have turned to Managed Services as means to control IT costs. In my case both Infrastructure and Application Development was outsourced, introducing new challenges to architects seeking to control technology complexity and cost through standards.
Cost reduction by control of technology diversity is the primary theory of most Architecture Standards efforts. The challenge happens when bids and fees from Managed Services Providers are higher when using "standard" technology. When a provider bids $1M for a project using "standard" tools, but $0.5M using non-standard, how does the EA team react? What will the impact of the new technology on infrastructure management costs be? Architects must be prepared for that scenario.

Gartner has written extensively about middle-out architecture, or the idea that we can "architect the lines, not the boxes" extensively. This idea has a whole new meaning when considering the managed services operating model.

Middle-out architecture allows more flexibility to develop applications and manage infrastructure because standards focus on the lines (interfaces) between components of the architecture. The approach allows freedom to design the components (boxes) according to drivers of the moment (goals, costs, state of technology) while maintaining control over how things fit together.

By comparison, a large company could have hundreds of technologies, each having two or more standard versions, each having additional documentation. Managing all this can be time consuming. Given the trend toward smaller teams, the resources are probably not available to maintain the necessary standards at a satisfactory level.

Using a middle-out approach, the EA team focuses on protocols, data formats, service level agreements, and non-functional requirements between components of the architecture. Since there are far less meaningful interfaces between logical architecture components than there are potential technologies to manage, the effort is substantially less.

In the previous example, the "old school" of EA would probably opt for the more expensive option offered by their vendor, assuming that the "standard" technologies will be cheaper to operate in the long term. The middle-out EA team evaluates the options against against a smaller set of interface standards and selects the cheaper option based on its ability to operate seamlessly with other architecture components according to required service levels.

In Conclusion

Considering these trends, a new operating model for tomorrow's EA Practice emerges -
The team is small, maybe six to ten people for a fortune 500 company. It delivers repeatable value through simple governance processes, focusing on principles and conformance to strategy. It develops detailed standards only when required for critical interfaces between major architecture components. The Practice has evolved.

The Quantum of Integration

2010-07-05T04:05:00.000-07:00

If you’ve read books such as the Dancing Wu Li Masters or are otherwise familiar with quantum mechanics, you have probably heard the idea that at its most fundamental level, reality does not exist until the observer interacts with it. At the subatomic level the very act of observing the world influences it - the same may be said for Enterprise Architecture.

A key skill for the Enterprise Architect is the ability to observe a complex system and describe it different ways according to the concerns of a stakeholder group. If you are a business person, you are interested in process, capabilities, benefits and costs. Software developers care about programming languages, component or service distribution, message queuing, etc.; while IT security is interested in preventing unauthorized access, keeping user audit trails, and protection of passwords. I could go on, but the point is systems can be described from different angles (IEEE 1471-2000 calls them Views, as does the Zachman Framework in reference to rows in the 6x6.)

While this is a great technique for description, I assert that the act of thinking about a system from different views actually influences the architecture.

Consider the elusive Integration Strategy. By that I refer to the problem of connecting things such that they exchange information seamlessly, cheaply and nimbly. The whole notion of SOA is an attempt to solve what started as an integration problem. If your view on this problem is focused on inter-application interoperability you probably are thinking about things like IBM’s Service Component Architecture as a framework for building applications. Not a bad idea.

Now, shift the perspective on integration from technology to business. First, the real problem is not that it is too difficult to integrate applications. That’s a subset of the broader issue - it is too expensive to access, maintain, and secure information required to carryout business. Furthermore, it is too costly to change processes in response to evolving business strategy.

This Business View may yield some different solutions than implementing an SCA. For example, you may ask why you have five processes that accomplish the same business purpose? Wouldn’t it be great if you could integrate those processes and have one that accounts for the variations in business context while maintaining overall integrity. You might embark on a business process improvement effort as a way to solve what at first looked like an integration problem. You may also ask why you need five different applications given a single future state process? You might go after application retirement and consolidation to reduce the number of required integration points.

Next consider a data oriented view - how come there are five different systems that maintain duplicative copies of the same product or customer record? This, you identify, contributes significantly to the same “integration” problems that too many process and applications did. Given this “ah ha”, you may latch on to Master Data Management as a way to solve the “integration problem” - in other words, you solve the problem by integrating data.

Please don’t get me wrong, the technical approach to application / data integration via SOA, SCA, etc. is still valid. My only suggestion is that a business and data perspective on the same problem may yield different, but complementary solution approaches. This is the heart of Enterprise Architecture - the ability to look at things both holistically, and from various views to come up with an architecture that is complete. Not fixated on a single solution to a perceived technology problem, EA should solve business problems with business solutions where technology plays a role.

Next time you find yourself staring a complex problem, wondering how you are going to solve it, put on a few different lenses and walk around the mess a few times. Watch reality change.

Who's On First?

2010-06-27T09:13:00.000-07:00

I was sitting in a meeting recently and found myself thinking of the Who's on First Vaudeville comedy routing made famous by Abbott and Costello back in the 1930s. Compare these two conversations -

Costello: "And you don't know the fellows' names."
Abbott: "Well I should."
Costello: "Well then who's on first?"
Abbott: "Yes."
Costello: "I mean the fellow's name."
Abbott: "Who."
Costello: "The guy on first..."
Abbott: Who.
Costello: The first baseman.
Abbott: Who.
Costello: The guy playing...
Abbott: Who is on first!

Compared with:

Enterprise Architect: "We need an Enterprise Roadmap"
Executive: "We have a roadmap"
Enterprise Architect: "But it's not an Enterprise Roadmap"
Executive: "What's an Enterprise Roadmap?"
Enterprise Architect: "It's a roadmap with an enterprise scope"
Executive: "The roadmap we have considers the Enterprise"
Enterprise Architect: "But it's just all of our portfolio roadmaps lumped together"
Executive: "But isn't it produced by Enterprise Architects?"

While the conversation on the right is admittedly made up and facetious, more elaborate versions of it go on everyday in many IT shops. We are having a communication issue that comes from a lack of shared meaning. Costello assumes Abbott understands the interrogatives used are the player's names. Abbott clearly does not. When we use words to describe what Enterprise Architecture (EA) is and what we do, are we being understood?
Here are examples of terms we use every day in Enterprise Architecture and how non-architects might interpret our language:

Term: Enterprise - EAs mean: The entire business; People Hear: Really large scale and complicated technology.
Term: Future State - EAs mean: A holistic model describing where the organization wants to be in the future; People Hear: a pretty picture of a new enterprise application.
Term: Pattern - EAs mean: An abstract generalization to a commonly recurring problem. People Hear: Detailed instructions on how to solve exactly the problem they have.
Term: Abstract Generalization - EAs mean: an general solution that applies to many situations; People Hear: αφηρημένη γενίκευση (yeah, its Greek)

The point is - we use our own lingo, but without shared meaning, we miscommunicate, do not deliver value and ultimately become irrelevant. For a soap-box sermon on this topic, please click over to Dinosaurs Are Extinct for a Reason on my personal blog - practicingea.blogspot.com.

The things that make us good at EA often make us bad at communicating what we do. We reason and speak in the abstract; we are systems thinkers; we consider the long-term, big picture; we are not concerned with next week, but do care about the next year or five years. In short, we are using interrogative pronouns as formal nouns and our colleagues often don't quite know what we mean.

Even the term Enterprise Architecture is a source of confusion and the subject of raging debate within the inner circles of our profession - but that won't stop me from offering a noun form definition:

Enterprise Architecture - a body of information that reconciles competing organizational forces and perspectives into a cohesive blueprint and roadmap. The Enterprise Architecture supports making the tough decisions necessary to get from where the organization is now (current state) to where it wants to be (future state) in an efficient manner.
At the end of the day it's about investing limited resources in the right people, process, financial and technology changes to gain competitive advantage (substitute ‘complete mission' for NFP and government organizations).
I end my first post with a few points about this definition and some suggestions regarding what we do about it, i.e. the so what? My definition suggests -

Architecture is about digesting a complex system and figuring out what to do.
Architecture becomes Enterprise when we start thinking about the entire business as a system and not just a software application.
The primary deliverable of any Enterprise Architecture team should be a future state description, just enough current state and an Enterprise Roadmap to get from here to there.
These deliverables are governance tools that allow organizations to match investment to strategy. Since our customers are not other architects, EAs must deliver these tools in a language understood by the business.

Assuming you agree with me up to this point, what do we do about all of this? Here a few ideas:

Establish alignment between senior business and IT executives about what EA is, and what value is expected. If EAs are delivering elaborate software design models rather than simple decision aids to help executives, the true value of EA is being missed.
Consider the reporting structure of EA if you have an EA team. Do they report to the head of technology infrastructure? (danger, Will Robinson), the CTO (better), the CIO (good), the CEO or Chief Strategy Officer (best).
Closely consider the EA team. Gartner calls out a common pitfalls of EA as having the wrong Lead Architect. The entire composition of the EA team must be evaluated. Have most EAs risen from the ranks of software development and infrastructure technology, or does the EA team have a balance of business and technology people?
Focus on the few key deliverables the EA team could produce that would have immediate impact to the business in realizing strategy. Make them simple, write them in business language, and include people, process and technology.

Do these and your answer to the question, "Who's on first?" is not "Yes".

Eating Donuts and Baking Bread

2010-05-30T14:13:00.000-07:00

Enterprise Architecture provides a keen platform for observing the executive and those of us that serve them; this post is dedicated to that relationship. I apologize that it doesn't have much to do with technology - for first time readers, I promise my next post will make up for it. In the meantime, indulge me as I attempt to offer a few observations on American corporate behavior and how these relate to EA.

The first behavior is what I call "Eating Donuts" and relates to a rule of mine -

"Donuts make you fat. They taste good for about 5 minutes and require hours of treadmill time."

To understand this, think about the tasty donut and your hunger. If you are full from a good, healthy breakfast, the likelihood of overdosing on those Krispy Cremes somebody brought to work is small. You may have one. On the other hand, if you are starving because you skipped breakfast, hoping to get into the office early and finish that report...well, let's just say those KCs are gonners and so is your waist line.

This happens all the time in business - a company that is starving for the short term satisfaction of ill conceived but immediately beneficial actions will rarely consider long term impacts. Results are figured quarterly - the benefits of the "donut" are too tempting. Organizations with out of control IT "Run-the-Business" costs have executives who like donuts and underlings who bring them plenty.

As EAs, we have to be the Jillian Michaels of our companies, offering long term solutions that keep us all healthy and fit. In the end the company will thrive and outpace competition.

One practical approach is to become watchdogs of the Cost-Benefit-Analysis (CBA) - it's that spreadsheet completed to justify projects for funding. Companies do not always make the connection between CBAs and technology cost growth. Examine a few for yourself; there is a good chance that continuing maintenance costs are typically and grossly underestimated. Put another way...show me a company that can't keep a handle on its technology costs, and I'll show you one that has a CBA problem.

"Fresh Baked Bread" is a second interesting behavior.

This one relates to another rule -

"Just because something smells good does not mean it will stay down if you eat it. The devil is always in the details."

Consider the following common corporate behavior - Director X presents a plan to solve problem Y to his boss Vice President Z. The idea seems aligned with the current strategy, uses all the right buzz words and is wrapped in a beautiful PPT. The boss gives the plan a "sniff test" and concludes it smells really good - like freshly baked bread. The VP gives the nod and reports to the SVP - "problem solved". Organizational attention turns elsewhere, this one is in the books...or is it?

Director X now attempts to implement the plan and runs into issues concerning the details of execution, probably because the solution is a variant of the the last three failed attempts. Ultimately the plan achieves some superficial success, but root issues are not addressed. Time passes, people turn over, nobody remembers exactly why we failed or who proposed the previous plans that did not work. Jump back to the beginning of the previous paragraph, rinse and repeat.

Here is an example from personal experience:

The problem we were trying to solve is how to effectively govern architecture; our solution was standard - an Architecture Review Board. We attempted three times in as many years to create an effective board. We tried different formats, different board compositions (technical, executive, mixed), and different support staff. Each of these iterations looked and smelled good, however the root causes of our ineffectiveness were never addressed.

The devil was in the details - we were trying to do both in depth review of an architecture and executive approval in one fell swoop via a grueling ARB meeting. Our projects would present to the ARB, expecting approval of their architecture only to find the executives needed for approval were not there and the underlings who did attend went down the rabbit hole on technical issues that could not be resolved in a meeting. Once we split the process into a broadly attended Architecture Review Meeting on a single subject and a regularly meeting group of executives to approve things (the ARB), we made real progress.

These solutions were simple - once we paid attention. As practicing EAs, we have a duty to identify root causes and propose simple solutions that eliminate sources of past failure, paying attention to the details. We must remember that the executives we serve are busy and they trust us because we are generally senior, experience people.

It is our duty to ensure we put the appropriate amount of yeast and salt in - and oh yeah, bake whole grain bread, not donuts!

All the Clams We Can Eat!

2010-04-28T05:05:00.000-07:00

"Pismo Beach, and all the clams we can eat!” declare Bugs Bunny and Daffy Duck in the 1954 classic, Ali Baba Bunny. They emerge from their tunnel, shovel and pail in hand, only to realize they are in the middle of the Arabian Desert. Scanning his map, Bugs goes on to blame their misfortune on missing the left turn at "Alba-koi-kee”.

Many organizations undertook Portfolio Rationalization, hoping to get to Pismo, only to end up somewhere else. They were missing an Enterprise Roadmap, which would have marked the turn left at Albuquerque. Portfolio management was a huge advancement for organizations seeking a means to handle their burgeoning inventory of departmental applications, however it ultimately fails because it is not driven by a cohesive business strategy and does not enable tough, enterprise trade-offs regarding limited resources.

In my November 2009 post, Real Architects Don't Wear Ties, I offer a definition of Enterprise Architecture,

"Enterprise Architecture - a body of information that reconciles competing organizational forces and perspectives into a cohesive, enterprise blueprint and roadmap. The Enterprise Architecture supports making the tough decisions necessary to get from where the organization is now (current state) to where it wants to be (future state) in an efficient manner. At the end of the day it's about investing limited resources in the right people, process, financial and technology changes to move to a desired state."

A key feature of that definition is the identification of an Enterprise Roadmap as the critical EA deliverable and a crucial organizational governance tool. The remainder of this post describes key characteristics of an Enterprise Roadmap and some hurdles you may encounter developing one.

Key characteristics of a successful Enterprise Roadmap:

It is written in business language - the roadmap is a tool to help executive's make trade off decisions regarding limited resources. The language and graphics in the roadmap must resonate with those executives. How much "technospeak" it can contain is a function of the business you are in and the executive's IT knowledge.
It is sponsored, and potentially co-written, by senior business leaders - this goes hand-in-hand with the first bullet. The best way to get the roadmap written in business language is to partner with the business in writing it. It is crucial to have a few key executives and the CIO bought in to the roadmap to assist in selling it to the rest of the business.
It illustrates the future state of the business in a compelling manner - successful roadmaps are broadly accepted by the business, adding a sales component to the development process. Its is not enough to have a technically sound deliverable. The future state description must be compelling. Consider "Case Studies" targeted at specific executives to tell a story about how the Enterprise Roadmap impacts them and drives outcomes they desire.
It describes the organization in terms of a functional capability model - an Enterprise Roadmap is not simply an aggregation of portfolio roadmaps, even though that is not a bad place to start. The roadmap over comes organizational and IT politics exactly because it addresses stakeholder concerns in a neutral way according to organizational capabilities. Gartner calls this a Business Anchor Model, while IBM provides a Component Business Model. You can see an example of one on slide 13 of this presentation. Use such a model to organize sections of the roadmap and provide a basis for aggregating financials.
It calls out gaps and identifies capabilities needed to fill them - the business is most interested in the capabilities IT will deliver, not the applications or technology. Put another way, unless the business is extremely IT savvy, talking in terms of future application or software platform names will mean very little. Instead, do an analysis of business goals against current-state capabilities, identify gaps, and define future-state capabilities as key objectives of the roadmap; then link investments to delivering these.
Dependencies are identified - be sure to identify critical dependencies between investments. Since resources are always limited, part of the roadmaping process will be constraining the desired "all in" investment total to something that is achievable. This inevitably means trade-off decisions. The roadmap should allow executives to know what investments must be funded and in what order to achieve desired capabilities.
It provides an aggregate financial view the future - one of the ways you know a roadmapping effort is sucessful is the question, "so how much will all this cost". The roadmap should come loaded with the answer in terms of financial models (charts and graphs). These models should illustrate total required investment and the impacts of capitalization on annual expense. It should also provide a projection of future impacts to the company bottom line (the benefits).
Progress against it can be measured - another question that indicates you are on the right track is, "So how will we know if we are achieving the roadmap?". A successful roadmap uses the capability milestones and financial metrics as markers to measure progress. A series of "interim states" can be identified in the roadmap that call out capabilities delivered and the impacts of those capabilities on business Key Performance Indicators (KPIs). This will go along way to making the roadmap compelling.
It addresses organizational readiness - a final question the roadmap must answer is, "Are we ready to do this?". Since an IT objective of the roadmap is to build confidence and credibility in the technology organization's ability to deliver, having a frank analysis of readiness will build credibility. Also, in developing the technology component of the roadmap, take care to avoid early solutions that the business is not ready for. As an example, an ERP or CRM technology might be indicated by business requirements, but if the business is not ready for the level of process change required to be successful in these types of implementations, recommending them early in the roadmap is not advisable. In this example, the roadmap can call out business process change management as a key dependency that must precede an ERP implementation.
It supports drill down to the detail - inevitably some executive will latch on to something in a roadmap and "go down the rabbit hole". The underlying detail to support the high-level direction of the roadmap must be available. Without supporting detail, a roadmap's credibility is in jeopardy. I cover some useful techniques for clearing political hurdles and overcoming objections next.
It illustrates the impacts on technology cost - a common requirement of most large organizations is to manage the cost of technology and almost always reduce it. Two main contributors to technology cost are application environment complexity and shared infrastructure cost. An Enterprise Roadmap should show how the proposed investments impact these over time.

On the journey, you may encounter a few obstacles; overcoming these is crucial to success. Here are a few -

Resources and organizational focus - developing a roadmap requires significant organizational focus and substantial time from senior executives. It also requires Enterprise Architects with the knowledge and skill to work closely and directly with business partners to get beyond technospeak and down to the brass tacks of what is needed. Because of this, expectations regarding the amount of time and collaboration required to create the roadmap must be set with the "C" level. If the "C" executives are not committed to the roadmap, the next tier of executives will not be available to the extent needed. Expect 6-9 months of continuous effort for a Fortune 500 sized organization's initial enterprise roadmapping endeavor.
Over coming line-of-business politics - the level to which executives are willing to trade-off benefits to their lines of business for enterprise ones will affect the severity of this obstacle. The difficulty manifests when influential leaders are less than enthusiastic about the roadmap because a trade-off decision works against their agenda and performance metrics. Organizational incentives are a contributing factor. When a manager's performance is tied to KPIs specific to their line of business and not the enterprise, this obstacle is more likely. This is where "C" level sponsorship is crucial - managers are less likely to oppose or drag their feet for an initiative that is strongly supported by the CEO.
Over coming IT Cost Allocation issues - since a roadmap should describe the proposed investment's impact on Total Cost of Ownership, the issue of IT cost allocation may cause problems. In my post, Calling Out Pesky Pachyderms, I name this issue as the big white elephant that many organizations do not want to deal with. In order to illustrate the technology cost impacts of the roadmap, you have to agree to what technology actually costs and assign accountability for that cost among portfolios that need to manage it. As an example, the roadmap model must have a way to indicate that the cost of a legacy accounting application is $XM, and that retiring that application will result in some % of the $XM in savings. Ensure that part of your organization's commitment to having a roadmap includes the development of a cost allocation model that will be accepted by business and technology executives.
Constraining the Roadmap - since most enterprise roadmaps start off as a aggregation of all business unit desires for IT investment, the total price tag is likely to be much more than your organization is willing to spend. The really hard work of a roadmap, once the "all in" financials are known, is answering the question, "what of all this really drives us to where we need to be?" Inevitably, trade-offs will be needed and projects will end up on the editing room floor. Trying to over come this obstacle in the midst of creating the roadmap can be extremely difficult because there may be the unspoken expectation among executives that this roadmapping effort will finally make some things happen in their business unit that are high on their agenda. The key to solving this is a strong, centralized IT investment governance body that includes representatives from all business areas. Make it clear that this body is the roadmap approving authority and responsible for setting priorities and making constraining decisions. Ensure this body reports directly to the CEO (not the CIO), and ensure the CEO is the final arbiter.

In closing, you may have noticed that I say little about the format of the roadmap or provide references to templates other than the anchor model. There are an abundance of roadmap examples out there; the Enterprise Architecture Executive Council has a nice package as does Gartner and Forrester. I deliberately stay away from this because I believe that the exact format of a roadmap is something each organization has to find for itself. Because the roadmap must communicate to business and IT executives in a way that they understand, it is very difficult to get it right when starting with somebody else's template. My suggestion for those of you starting the journey is to research examples, but start with a series of questions the roadmap should answer. Work with leadership to ensure you are answering the right questions, then create a blank presentation with slides for each question or group of questions. You can then have conversations with decisions makers about the information contents of each slide that would best answer the target questions. Last, design some models, charts or tables of data as appropriate to supplement bullet text and narrative for each slide. Then iterate.

Before you know it, you'll be in Pismo eating Clams!

Dinosaurs Are Extinct for a Reason

2010-03-24T04:54:00.000-07:00

If I asked why dinosaurs are extinct, your answer would probably have something to do with climate change and how the dino’s didn’t adapt very well. In other words, the Earth’s ecosystem changed such that it no longer supported dinosaur biology - so they went away. If I asked why your application portfolio still has dinosaurs (aging, outdated applications or useful applications on aging technology), what would the answer be? Maybe it’s because your IT ecosystem still supports them?

Here’s what I mean -

A common technology management practice is to provide discretionary funding to application portfolios for both maintenance and small project work. How does the IT ecosystem incentivize them to spend this money? The primary reward for portfolios is successful delivery of solutions that provide hard benefits to the business (by hard I mean real dollar savings or income). When hard decisions are inevitably made regarding portfolio’s discretionary budget, what do you think those decisions do?

They move money to projects that deliver more hard benefit to their business customers. The problem is that hard benefits are, well, hard. The have a tangible impact to the company bottom-line, which results in bigger bonuses and advancement - rewards. Application maintenance, simplification and retirement has no such rewards. The result is an IT ecosystem that constantly builds new stuff and never gets rid of the old. Why are we surprised when the dinosaurs just won’t go away?

A common approach to solving this problem is the application modernization program - that is, roll up all the platform upgrade and retirements into one big ‘program’ level initiative, give it lots of visibility, associate lots of ‘benefit’ to it and just get it done. Their are two problems with this approach:

Nobody can believe the price tag. Here’s the deal - technology upgrade and retirement is expensive. Most business cases for new applications grossly underestimate the downstream maintenance tail incurred. If the true cost of ownership was understood, the underlying benefits would be eroded and what’s the fun in that? Again, the ecosystem rewards short term realization of hard benefit, not responsible decision making based on total cost of ownership and total return on investment.
Second, the benefits are dubious. In other words their is not wide spread agreement that doing all this work will really generate the savings (hard benefit.) Many in the organization treat the notion of retiring and simplifying as a way to drive down cost with a ‘nod and a wink’. When hard budgetary decisions are made about limited resources, what is the first program that gets cut? You got it.

As as result, most application modernization programs either never get off the ground or fail to get the funding to stay ahead of the upgrade wave; applications become antiquated adding to the work as fast or faster than the program can care for them.

Getting rid of applications dinosaurs is a major undertaking that can be accomplished according to one of two strategies:

First, make it a board level mandate and not benefit driven. This works for mature organizations that realize application business cases of the past did not properly account for the support cost tail.
Second, change the IT ecosystem (the biology) and watch the dinosaurs disappear over time.

Since the second case is most likely, here are a few more ideas on how to make this work. The central theme is changing the incentives to drive behavior:

First, establish an IT cost accounting model that allocates full application support cost back to the portfolio. When I say full cost, I mean both development costs for maintenance releases and a charge-back for a portion of shared infrastructure costs. I understand that ‘charge-back’ can be a dirty word in many IT shops. I use it here purposefully to indicate that charging portfolio’s for infrastructure support costs is an accounting facility to track technology run-the-business accountability. I also understand that implementing a shared infrastructure cost model is really tough because the business sponsors of the portfolios may not willingly accept the cost accountability. This is equivalent to playing ostrich by sticking your collective head in the ground. Many organizations transfer shared infrastructure costs to an Infrastructure executive so that they are “not the portfolio’s problem” after delivery. Guess what behavior results? Under estimation of application total cost of ownership to justify delivery and resulting infrastructure bloat.
Second, implement a zero sum gain policy that reduces funds available for business demand as application maintenance and shared infrastructure costs grow. Once portfolio managers have to show charts that illustrate year-over-year reduction in business demand investment because of increased maintenance and support costs, behavior will change. These managers will have to adopt a simplification and maintenance cost reduction strategy to obtain the resources necessary for business demand investment in solutions with hard benefits.

Taking these two steps aligns portfolio incentives with the goals of the Enterprise. Misalignment of portfolio’s and the enterprise is one of those big white elephants in the board room that I discuss in my post, Calling Out Pesky Pachyderms. Get rid of this elephant and change the IT ecosystem.The result? Yup - those dinosaurs go away.

BTW...I'd like to give credit to a few of my colleagues whose discussions along these lines have helped clarify my thinking - Bill Van Emberg and Joel Freiburger

The Anthropology of Data

2010-03-08T17:35:00.000-08:00

I was asked recently where I though data was going; after mulling my answer for a few days I decided I’m not happy with it. My new answer is this - data is moving from being a matter of archeology to anthropology.

While I admit the analogy is obscure, consider this - we have been collecting electronic data for about 50 years now. The largest organizations now have warehouses that contain petabytes of it. Furthermore, there is no end in sight. As we become better at digitizing information and assigning useful metadata to it; we collect more and more. How will we use all this data in the future?

Even now, the most common use cases involve spending enormous effort moving, cleansing, enriching and transforming data into a central stores to generate tabular reports. The value of the data we collect therefore depends on the skill and technology used to clean it, connect it and create reports that provide historical information in the hopes that we can make good decisions about the future. In other words, our data is archeological in nature - wait until its dead, move it into a secure place and inspect it.

Our ability to collect data has always outpaced our ability to make use of it, therefore we will always have more of it than we know what to do with. While the ‘move it to the warehouse once it’s dead’ approach will continue to be helpful, tomorrow’s successful organizations will adopt approaches to data that ire more akin to anthropology. Think about this - the most useful data is not old and dead, it is alive and evolving. While we can make use of old, dead data; the most useful technology will allow us to inspect the culture of living data and use trends and behaviors observed in past to allow predictions of the future.

Compare these two scenarios -

#1 - Archeological Approach

At a certain point in each year, shoppers start buying orange juice and tissues together and in greater quantity. Not-So-SavvyMart takes the archeological approach - they discover this connection by mining the warehouse and concluding that during cold season people need tissue and want the vitamin C in OJ. As a result of this expensive analysis, they eventually co-locate these products to increase sales during certain times of the year. The archeological pattern - collect data, mine data, draw some “ah ha” conclusions, take some action, increase profit. Boy that took a long time.

#2 - Anthropological Approach

This approach recognizes the connection between OJ and tissue is one of many connections between products that come and go; the culture of data (what people are buying and why) is most useful, however, when trends can be immediately recognized and taken advantage of. In this second scenario, SavvyMart employs RFID sensors and smart shopping carts to track what its customers are putting in their shopping carts in near real-time. They are also tracking where their customers are going and the patterns they follow through stores. Rather than wait to store and mine this data, they have designed a predictive model that spots trends in products purchased together. Rather than ask, “why” and take action to rearrange product placement, the monitors on the smart carts simply suggest related products when the first is bought, possibly even offering digital coupons. Managers use a product placement data mash-up application to suggest end-stand arrangements that optimize related product purchase opportunities based on the evolution of cart patterns and product purchases.

Next SavvyMart’s procurement system begins noticing sales trends and advertises its desire to purchase more of high demand items via its network of suppliers and the Good Relations Ontology. SavvySupplier notices the increased demand and reduces its cost on large volumes, making this offer back to SavvyMart automatically without human intervention.

Notice the different pattern here - evaluate raw data, sense patterns, use past behaviors (customers often purchase products together) to create predictive models (what products will be purchased together), and act on data using advanced metadata techniques (ontologies). This is the anthropology of data - I assert that tomorrow’s successful organizations will be the one’s that leverage it most effectively to gain competitive advantage.

As part of the anthropology, here are some additional contributing trends and predictions:

The Data Cloud is the next big Cloud. Persistent Data will continue to grow, that’s a given. Cloud Platform Storage (an extension of Scale-out storage, for example Google’s AppEngine) provides a technology that is significantly lowering the costs of extremely large scale data storage environments but it is not without drawbacks (reference David Chappell’s February 27th 2009 blog). Most prominent is that nobody seems to know how to make a relational data store scale to really massive data volumes; this is because relational data stores scale up but not out. If you follow this trend, then the logical conclusion is that tomorrow’s technology for accessing massive amounts of data will have to be really ‘smart’ because we will not have nice little query languages like SQL to help out.
Legal requirements for data are not going anywhere, driving the expectation that data will be stored and accessible. I could reference all kinds of information on the impacts of the 2006 changes to the Federal Rules of Civil Procedure, but I don’t need to. Think we all understand this; however when you combine this fact with the above trend you start to get the point. We are collecting a massive amount of persistent data and there is a growing legal expectation that we can access it. This adds a regulatory burden to our need to have really smart ways to access lots of data.
The availability of processing power will enable replacing traditional ETL with virtual ETL and near real time knowledge extraction. Traditional ETL jobs run in batch processes and move massive amounts of data through cleaning, transforming, enriching and loading routines. The result is a secondary data stores that can be queried by Business Intelligence technologies such a multidimensional OLAP. The problem with this is it only runs so fast, requires a lot of transformation logic - e.g. time and expense. As processing power increases and smarter ways query de-normalized, dirty data emerge, technology to extract that data and move it to useful forms will progress. I use the term Virtual ETL to refer to these types of near real-time data movements. Examples of this today exist in very primitive form as database materialized views and Business Objects Universes.
Data collection will move closer and closer to sources and become pervasive - think about what RFID technology has done for data. Now we can collect information about products that are on retailer’s shelves. We can also put sensors in shopping carts and track the interactions of customers and products in a store. What will sensor technology do to revolutionize insurance? Think of how that business will change once we can detect and prevent losses for many risks that are considered ‘uninsurable’ today.
Information Ontology technology will marry Predictive Analytics and Cloud Storage to enable smart mining of dirty, hierarchical data collected in near real time on cloud platforms. With this prediction, things start to get really interesting. Imagine a near future in which data collection spiders, like today’s search engines, find and transfer actual data or pointers to cloud storage devices in a massively scalable, hierarchical and dirty format. Smart query languages based on ontologies for specific knowledge domains perform light weight (and virtual) ETL on this data to create knowledge stores. Predictive models can then be run on this knowledge, again leveraging Ontology languages to create business knowledge and predict future behavior - essentially delivering the information we get today from SQL, warehouses and batch ETL but faster, and with massively more data.

My flight of fancy could go on, but you get the point. I answer the question, “where is data going?” very simply - it is moving towards being useful in ways that it has never been before. We will be able to leverage techniques proven in traditional Business Intelligence on massively large amounts of information in near real-time. This will allow us to study and leverage cultures of growing, changing and organic data to make better decisions faster. Organizations that get this ahead of their peers will have a competitive advantage.

Welcome to Frameworkville

2010-02-18T16:02:00.000-08:00

Welcome to Frameworkville, the place every Enterprise Architect wants to live! As you can imagine, it's is growing by leaps and bounds. The south subdivision, Zachman Heights, is charming with its venerable View trees lining neat streets arranged in a perfect matrix. The fastest growing suburb is TOGAF Landing; lots of people are moving there to live near the orchard of Content.

So there you are, cup of Kool Aid in hand, having just moved into this blissful town with the rest of your EA family. Suddenly your cubie buddy’s phone rings. He hurries quickly to the big bosses’ office and return in minutes. Head hanging low, he begins to clean out his desk. Guess he won’t be moving in to Frameworkville with the rest of the team. What! Mary, behind you, is also on the long walk back from the boss. What’s going on? The three of you just went to training and where going to spend the next month populating the the enterprise continuum with architecture artifacts according to the content metamodel.

Reality check - your team just went through a down sizing; where economic reality meets the ideals of an Architecture Framework. That reality often dictates that EA stay focused on delivering immediate value rather than ramping up to a framework that dictates abstract deliverables created through arcane processes. .

In Digging to China - Just Because You Can Doesn’t Mean You Should, I suggest that tools are not the way to drive EA maturity. I make the same argument here. Please do not get me wrong, I’m a big fan of Architecture Frameworks, when properly introduced into organizations that are sufficiently mature and operate at appropriate scale. I occasionally speak with EAs from other organizations that are investigating or have adopted a Framework as a way to drive architectural maturity. My thought - been there, done that, doesn’t work!

Like tools, Frameworks are a significant step in the evolution of an EA practice and every team should strive to have one. I’ll even go further to argue that without a framework, deliverables will have consistency and quality issues. That said, do not think that a framework IS the roadmap to maturity. Here is why -

We are in the business of communication. At the end of the day, if EA work products are not used to drive decision making, what good are they? An analyst colleague made a keen observation a while back - EAs do not do EA. EAs lead the organization in the practice of EA.

If EA process cannot be simply explained, and if deliverables are not immediately useful, we will soon become extinct (see Evolution Was Bad for Neanderthals) because we do not contribute value. Unfortunately, ease of understanding is not a characteristics EA frameworks. Anybody who has attempted to absorb one can witness to this. Do I hear and Amen?

Having a framework is a milestone along the EA maturity path; but please consider a couple of things before you convincing the CIO that one is required now:

At what scale do you operate? For example, my current team is about 20 architects at a $7B company with 7000 employees. We get along reasonably well without a formal framework. Frameworks become more useful at larger scales because they enforce discipline that can be difficult to attain otherwise. Federated architecture teams benefit even more because frameworks keep geographically diverse EAs working consistently.
How mature is your IT shop? Since EA is about communicating; how easily will IT executive’s “get” the framework and its deliverables? Will the CIO tolerate “two steps back to take three forward”? Implementing a framework can divert focus from immediate priorities while the team gets trained, begins to execute and starts speaking in the new lexicon (which may sound like tongues to the rest of IT - metamodels, continuums, views, etc.)
How mature and IT-oriented is your business? A focus of any framework effort should be the production of deliverables that guide the business towards better investments in technology. If you have to spend time decoding framework deliverables into pretty pictures for the business, the framework return on investment is eroded. If your business partners think architecture is just ‘some IT mumbo jumbo’ and just want solutions delivered according to their orders, rethink how ready you are for an EA framework. Sucessful framework implementations bring business and IT together.

If you are part of a young EA team, what should you do? Here are some ideas that I will close with -

Do adopt IEEE 1471, this is a very simple set of concepts, a meta-framework if you will, that other frameworks such as TOGAF are built upon. The specification defines ideas like stakeholders, their concerns and how architecture views address the concerns. Spending time figuring these things out and producing products that address stakeholder concerns is a quick way to mature and demonstrate value.
Do define a set of measurements that establish how the EA will make a difference. Execute on making that difference an then come back with the data.
Do create an EA Charter that defines why EA exists and what organizational expectations are. Incorporate the metrics defined above. Use this as your organizational framework for executing EA.
Do get closer to your business. EA is about business, not technology - at the end of the day, if the EA team’s work has not made a difference to the business, then it has missed out (See Real EAS Don’t Where Ties.)
Do get familar with EA frameworks and cherry pick good ideas that your organization can easily adopt and that generate quick value. There's lots of good stuff in framework specifications if you spend the time absorbing the key ideas.

At the beginning of the journey is all about building credibility, culture and synergy. Once the business and the CIO are coming to EA because the team that can identify opportunities and clear obstacles, then you are ready to say, “if you think this is good, wait till you see what I can do with a Framework!”.

The Borg Were On To Something

2010-01-22T17:47:00.000-08:00

For those of you who weren't fans of Star Trek - TNG (weren't we all?), the Borg were a race of cybernetic organisms functioning as a single entity, roving about the universe "assimilating" planets into their Collective consciousness.

Besides indulging my geeky SciFi disposition, what does this have to do with EA and how we practice it...? While I'm not suggesting we become a civilization of mindless drones led by an evil queen, I do think we can learn about the power of the collective from our fictional friends.

In Blind Man's Bluff, the author recounts how the phenomenon of collective consciousness was used to find a lost submarine. A number of people were asked to put a pin in the ocean, after being given a very large area where the boat could have gone down. These people had no specific knowledge; they were asked to guess. The area where the most pins showed up was refined with another round of blind pin-pushing and so on... focusing their search in the smaller area of the ocean eventually identified, they found the submarine.

There is enormous power in the collective consciousness of our society - the emerging trend of Social Media Applications is rising to tap that power and put it in the hands of our leaders.

"Social media is media designed to be disseminated through social interaction, created using highly accessible and scalable publishing techniques. Social media uses Internet and web-based technologies to transform broadcast media monologues (one to many) into social media dialogues (many to many). It supports the democratization of knowledge and information, transforming people from content consumers into content producers." - Wikipedia, Social Media

While I could find no common definition, a Social Media Application is built upon or into traditional social media software for the specific purpose of furthering an enterprise's mission. Social Media Applications can be either externally or internally facing, however the future will blur this distinction.

In Social Media Today, author Josh Gordon discusses the Coming Changes in Social Media Business Applications; according to him, "companies are now viewing social media as a primary tool of customer engagement, enabling lead generation, immediate customer contact, and customer interaction." In addition to this obvious application of social media for customer relationship management, I assert that the internal use of social media applications is just as important for business', especially large ones.

Fortune 500 companies, with thousands of employees, potentially spread over dozens of locations have difficulty making internal connection need to excel. Traditional solutions to this problem include ERP and the Data Warehouses. Think about the premise of these tools - collect all application functions or data into a central logical or physical location then integrate it to provide centralized decision making power and data. There is just as much power in connecting the people of an organization through Social Media Applications and it much cheaper. Social Media Applications have this wonderful property - they are self organizing!

An example of this is the current Crisis Camp and Crisis Common efforts supporting the Haiti disaster. These groups are busy configuring Social Media Applications to harness our collective power to find people and reunite loved ones. These efforts have organized themselves overnight with no central direction. In a matter of days, the power of the social collective is rushing help to Haiti in ways that no amount of money could do so quickly.

I work in commercial insurance, which is essentially a "people" business. Our company's people sell contracts that indemnify clients from risk through agents who work hard to maintain relationship's with their customers. There is very little product differentiation in the market, so selling policies is a matter of building and maintaining relationships and serving customers in claims. Supporting this external customer relationship building exercise requires that the people inside my company know each other really well. The worse we are at finding answers and identifying opportunities for serving customers and cross selling products, the less competitive we will be.

While I am not a proponent of "Groupthink", there is enormous potential in providing access to a company's social web to leaders who could tap it for knowledge on market segments, customer needs, production bottlenecks and engineering issues. To often, the people who know the market best are working level, customer facing employees or engineers many levels removed from the board room.

As an example, consider GE. In his book, Judgement: How Winning Leaders Make Great Calls, Noel Tichy recounts a the story of the $1 Billion GE Appliance fiasco. They fielded a new, smaller refrigerator with a new compressor technology. The product was a huge success, however the engineers who knew about design defects were not in the go-to-market decision making process. The end-result was a major product recall that cost the company dearly.

In the new age of social media applications, the distance between the leaders and the engineers would be nothing more than a few mouse clicks; had the technology existed and had GE implemented it, leaders could have easily accessed the engineering opinion through internal social media. Even if they had not thought to ask, it is entirely possible that an engineer with unregistered concerns about product design could have posted information to his personal home page or used other social media channels to raise awareness of the problem. While Social Media Applications would not have guaranteed avoidance, they could have offered conscientious management an avenue to tap the corporate collective to make a more informed decision.

As EAs, we are still primarily focused on ERP, BI, DW, ECM, name your 2-3 letter acroynm for big, expensive applications and information integration platforms. Today's social media software provides a cheap, "People Integration" platform for very powerful connections externally with customers AND internally between parts of a business.

I predict that the tomorrow's most successful businesses will be the ones that harness this power to change the dynamic of marketing, supercharge the connectedness of their employes and put the power of the collective into the hands of leaders. Tomorrow's successful business will be less a separate entity operating for the benefit of its shareholders measured strictly by P&L. It will breakdown the barriers between company and customer, forming a dynamic social organism that understands stakeholder's needs and responds organically.

I end by challenging our profession to think about this, evaluate our strategies, roadmaps and enterprise architectures and introduce the power of the Borg into our organizations.

THE Essential EA Tool Kit

2010-01-05T07:35:00.000-08:00

My first post of the year deals with the essential tools of Enterprise Architecture - an internal compass, judgment, courage and finesse. I believe these soft tools and the skill to use them are as important as technical acumen to our success as Enterprise Architects.

Imagine, 2010 has come, you are at your desk ready to start the new year off and the first crisis lands squarely in your lap. The architecture lead for a multi-million dollar technology investment plops down in your officle (office/cubicle) and voices a concern - his program has circumvented process and standards, moving into its construction phase without ARB approval. Furthermore, the implementation team is procuring a major software as a service platform without any involvement from technology architects or security. Last, you learn business expectations regarding delivery dates have been set and the software acquisition contract has been signed.

Aside from the obvious process and policy deficiencies that allowed this in the first place, how do you handle the news? I mention this scenario because it illustrates a point - the most important tools for EAs are often an internal compass (the gut instinct that something 'is not right'), the judgement needed to approach the situation correctly and the courage to act on convictions, regardless of our position in the organization. A final tool, finesse, allows EAs to handle these situations in a way that adds value to the enterprise.

In his blog, What's the Difference Between Architecture and Design, Tom Graves asserts:

"Architecture faces towards strategy, structure and purpose, towards the abstract.

Design faces towards implementation and practice, towards the concrete...

Architecture without design does nothing: it can too easily remain stuck in an ‘ivory-tower’ world, seeking ever finer and more idealised abstractions.

Design without architecture tends toward point-solutions that are optimised solely for a single task and context, often developed only for the current techniques and technologies, and often with high levels of hidden ‘technical debt’."

The point - as Architects of the Enterprise, we have an obligation to consider strategy and purpose; we are forward looking, considering broader consequences and long-term impacts. We serve as a check and balance to application designers that seek the path of least resistance to solve problems at hand. EAs need an internal compass that 'points North' when the pressure of delivery in upon us.

Here are some passages from a book I'm reading that is partially the inspiration for this posting, Judgment: How Winning Leaders Make Great Calls -

From Chapter 2 on the Framework for Leadership Judgment -

"... the mistake people make in framing crisis judgments is being too short-term... a short-term fix uses up resources and is often not productive in getting toward the ultimate goal... [in pursuing the short-term] you can drift off into activity that is gonna make you feel good, but if that activity is not ultimately accomplishing what your mission is, then it's wasted and you're going to have to go back and do it [the right thing] anyway." [BTW...I call this 'eating donuts', a future blog subject.]

From Chapter 4 on Character and Courage -

"... having character as a leader is, if nothing else, the acceptance of consequences and responsibility."
"... without strong moral fiber and a sincere desire to put the greater good above personal gain, a leader's judgment will stray too often to the pragmatic and expedient. The hard choices that good judgment requires will not get made."

In absorbing these statements it occurred to me that, in addition to a companss, good judgment and courage to act are essential skills for EAs. Too often, I think we get mesmerized by our own technical depth and skill, forgetting our fundamental charge as ENTERPRISE Architects - to watch out for the enterprise, think strategically, identify situations that 'aren't right', make key judgments about how to handle them and then act with courage and finesse. In addition, we become excessively pragmatic, shying away from the right (but hard thing) by convincing ourselves that it is just not possible and therefore a waste of our time.

I conclude by challenging our profession to think on how we develop soft skills and execute our jobs using essential tools - an internal compass (character), judgment, courage and finesse.

Compass - we need to have good gut instincts about what's right and wrong. A good EA does not need a business case or a complex architecture description to recognize situations that could have adverse long term impacts to the enterprise. Developing this sense requires forethought and principals. We need to know in advance where our boundaries are.
Judgment - as EAs we are chronically pulled in many directions. A critical skill is identification of the correct strategy and critical decisions about a situation that will enable a positive resolution. As part of the judgment process we must identify and engage appropriate stakeholders, marshal resources and support executives in making tough decisions.
Courage - to paraphrase a further passage from above, 'character without courage' is useless'. As practicing EAs, with working level relationships and 'ears to the ground', we are the first ones to realize a problem. Too often, we find ourselves in the position of 'whistle-blower'. It takes courage to address the problems in a constructive fashion. It also take courage to overcome the 'momentum of the pragmatic' and do the right thing even if its not the most expedient.
Finesse - In a lively discussion on LinkedIn's Practicing EA group titled Governance Is About Saying Yes, I assert what may seem like the opposite opinion - that EA is about finding a way to rationalize capitulation. If we dig under the surface conclusion, what I am really saying is that we have need of a compass (to give us instinctual direction), courage (to deal with the situation), and finesse (to figure out how to deliver the desired short-term value our customers are looking for in a way that meets long-term strategy and the company mission.) Quite often finesse involves saying "yes" with accountability for the short term 'technical debt' we carry. I'll post more on this later.

Happy New Year and thanks for your readership and comments.

Calling Out Pesky Pachyderms

2009-11-21T04:58:00.000-08:00

A roadmap that enables business objectives is the crown-jewel of an Enterprise Architecture (EA) team; however there is a big, white elephant sitting on the key to delivering one. I'm going to call out that elephant; I hope that stating the obvious will help get him out of the room: Delivering a roadmap to the future cannot be done without transparency and accountability for technology costs expressed in terms of applications. The elephant is the the political challenge. This is a simple thing that working-level EAs instinctively know but it appears to get lost in the ether of organizational politics.

Why is this so important? What's more, why is this so difficult? EA is challenged to create architectures that enable more business delivery while holding down technology annual maintenance costs. Without a clear picture of IT run-the-business costs this cannot be effectively done; these costs may be allocated to per-seat variable, fixed infrastructure and applications. Understanding infrastructure and per seat spend for storage, servers, software maintenance and desktop technology is generally not difficult; companies take depreciation on much of this. The real trick is agreeing to application cost allocation.

Many large organizations that have grown by acquisition and then moved toward IT centralization have an enormous inventory of legacy applications and history of departmental spending on very large applications characterized by low user count, aging technology and point-to-point integrations. Monster ERP applications may have been implemented as part of the effort to centralize. Throw enough of these old and new applications on the pile and you've got a mound of expensive spaghetti. A major component of the enterprise roadmap is the application modernization plan to 'de-spaghettify' the environment by retiring, replacing, and consolidating - key drivers behind the popularity of SOA, Cloud computing and out-sourcing.

"Let's have a look at the roadmap" says the CIO as architecture slides the application modernization price across the table face down on a piece of paper (with breath held). You can see where this is going. We all know by now that application modernization and consolidation is hugely expensive; organizations cannot get over their gut instinct that it's a game of whack-a-mole - costs eliminated in portfolio A will just pop up over in B. Assigning costs to applications and getting business accountability is absolutely critical to selling the roadmap. When accountability for application costs accepted by the business, board conversations shift from, "why is IT so expensive" to "why do we need all these applications?" Wow, talk about turning a conversation on its head - why is this difficult? Ah, let's get back to the elephant.

Assigning cost accountability to applications forces transparency and leads to board-level attention on individual investment decisions that may cause angst. All those applications are there because or or more business executives wanted them. When the executives were part of an acquired company or previous management regime, this is not an issue. When the executives who sponsored applications are still part of the management team and highly vested, you see the problem. Also tested is the political will to over come department noise resulting from discussing the retirement of sacred-cow applications. Don't know how much more plainly to say it - that's the simple truth.

Oscar Wilde said, "The plain and simple truth is rarely plain and never simple". Couldn't be more true in this situation. The organizational tightrope that must be walked by management to identify and overcome obstacles to application cost allocation can be staggering. The reward for getting the elephant out of the room is business accountability for the hard decisions needed to simplify the application environment despite paranoia about the whack-a-mole game and the 'not my application' syndrome. Making these decisions will fund the roadmap, which is a very good thing.

Digging to China - Just Because You Can Doesn't Mean You Should

2009-11-14T04:37:00.000-08:00

Imagine it - there you are, armed with a shinny, expensive, new architecture tool that your boss has just gone way out on a limb for. You got the training, a bit of organizational momentum and a ton of great ideas about how this tool is going to enable some great architecture work. What should you do first? Current state is a mess and future state is not even a twinkle in management's eye. Following the logic that you can't build a new house until your current house is clean you do the sensible, pragmatic thing by taking on the architectural equivalent of house cleaning - documenting the current state.

Along the way, you conclude that one can't really have a clean house unless the foundation is inspected; up comes the floor, in goes the shovel. After a month you're staring at a huge hole and a few of your coworkers, either by osmosis or coercion, have chosen to dig alongside you. You gain a bit of organizational recognition for your current state analysis / hole digging. Someone asks, do we really need a big hole? "Shut up and keep digging" you and your crew respond.

After a few months, it dawns on you that there is no foundation. With blistered hands, a huge pile of dirt in your once cleaned house and being no closer to "China", your teammates crawl up out of the hole, dust their britches off and find better things to do; mumbling about the damn tool that got them digging in the first place. Next thing you know, organizational priorities shift, people wince at the mere mention of the T-O-O-L. Annual maintenance is not renewed in the name of fiscal responsibility; you can forget about all that great architecture work.

This mostly true story has three points - 1) Doing current state first, then spending too much time on it is a trap [note 1] 2) it takes maturity in your EA practice to be able to successfully leverage a tool, and 3) acquiring a tool before you are ready makes the trap that much more tempting.

Simply put, Enterprise Architecture is about executing architecture analysis on the enterprise to define a future state and roadmap to it. The roadmap requires current state analysis, the questions are when and how much? Having an EA Tool, like System Architect, ARIS or Troux [note 2], makes it possible to dig deep into your current state defining the complex relationships between business processes, applications and technologies. But how much current state is needed and when should you do it? The opening story illustrates with tongue-in-cheek, a very real, and painful personal experience. Given a sophisticated architecture tool and the option to use it for current state or future state analysis, current state is very tempting.

Current state analysis is straight forward - you know at some point you have to do it anyway. You've wanted to "clean the house" for a while because architects hate dirty living. Future state analysis requires creativity, organizational politics and commitment that takes along time to build. Because of these factors, I'd venture to guess that many EA teams go for current state first, then, finding they have the tools, begin the journey to China. The trap comes when the complexity of detail available in the current state analysis tests the resolve of your team and the value of the effort. By the time you decide to stop digging, the diggers are soured to the tool (EA tools are complex and unwieldy still) and organizational infatuation has moved on to something else. Your opportunity to achieve your real objective, defining the future state and roadmap, is gone.

My first recommendation from this diatribe is to protect yourself with some principles (EAs like principles) , for example - just enough current state and after the future. When you are considering what to do about road-mapping, with or without a tool, focus on future state. Its hard, but its also the point of EA.

Current state is only useful in so far as it enables a roadmap and the business case investment in achieving the future state. While there is merit to documenting every conceivable relationship between technology, applications and the business , its not the primary benefit of EA. EA is about moving to the future, not configuration managing the present.

This brings me to my next thought about EA tools - don't forget basic EA truisms, like, "its about people, process AND technology". Truth is, EA tools are still emerging; none where conceived from the beginning as "EA" tools in the broader sense. It takes a significant amount of maturity in an EA practice to 1) avoid spending too much time on current state and 2) deal with tool quirkiness for the benefits offered. Make sure that your path to tool acquisition accounts for the people and process aspects of your EA practice and that you are really ready for the power and the pain an EA tool can provide.

My second recommendation for budding EA teams is that you stick with Visio, Powerpoint and Excel for a while. This will force you away from complexity because the tools don't support complex analysis and data management. In EA, simpler is often better because your non-EA executive audience wants a simple picture of the new house you are architecting for them not a hole in the ground.

Once your client (the business) is excited about the future state, then create detailed technical blue prints and conduct just enough current state analysis to justify the investment. By this time, you'll probably need that tool.
_________________________________________________
Note 1 - See pitfall number 5 from Gartner's top 10 EA pitfalls.
Note 2 - See Enterprise Architect Tool Selection Guide from the Institute for EA Development

Evolution Was Bad for Neanderthals

2009-11-10T08:50:00.001-08:00

What if we could use some 'proven architecture techniques' to come up with a common definition of EA -- then use that definition as a call to action within our own organizations (and make ourselves ancestors to the next generation)?

Imagine - a group of EAs, coming together informally on line to reach a consensus on what it means to be an EA and then carrying that definition to their organizations to actually do something. Huh! Could be powerful. Could be actionable. The point: as a community of professionals who profess to know how to move complexity into action, we need to eat our own dog food.

In my last post I offered a definition that posits EA is the use of proven architecture techniques at an organizational level to achieve benefits such as an actionable plan and governance in the face of complexity. So here we are in the face of some organizational complexity; we have a community of intelligent, experienced and articulate professionals, all with opinions about what it means to be an EA. In fact, with so many opinions, it is difficult to arrive at a consensus in order to harness the power of a common definition and then go do some stuff in our organizations or with our customers.

So let's take some action. I'm a "new" EA - in third year as an officially titled EA, even though I now realize I have been doing EA for years. I've been educating myself on exactly what proven architecture techniques are. Boiling down the essence of the the "xAFs", 1471-2000, etc., here are some simple steps that we could take.

Separate ourselves into stakeholder groups that have similar concerns then document those concerns. For example those of use that are former business people will have different concerns from infrastructure people.
Decide on common principles and requirements for an EA definition (without defining EA.) Examples - Principal: The definition should be simply worded and as brief as possible without compromising meaning. Requirement: The definition must be actionable.
Decide on a few "Views" of EA that address various concerns. For example, a Business View would address the business people's concerns, while a Technical View would address engineering concerns and an Application View would speak to those with a software development background.
Split into subgroups and develop the Views. Each view could consist of principles, requirements, a model and a candidate definition.
Compare the views, identifying the similarities and friction points, and then identify the enablers and inhibitors to arriving at a common definition.
Reach compromises on the friction points and inhibitors; use the similarities and enablers to do this.
Define EA (ta-da'!)

With a nifty common definition in hand, we can next analyze the current state of EA; then, based on our definition, define future criteria for use, and create action plans for our organizations (roadmaps).

Is anybody out there interested in doing this? It will be work, but also a chance to prove our craft. Otherwise I fear we are Neanderthals and that is bad.

Real EA's Don't Wear Ties

2009-11-01T05:16:00.000-08:00

The title underscores a reality of the state of Enterprise Architecture. Stereotypically, "real EAs" are senior, Mountain Dew-drinking, software developer's that cut their teeth on death marches during the dot-com glory days. These folks would not ever think about wearing a tie. A new-age EA is emerging however - the business professional with as much background in business management as technology. These folks are far more likely to wear ties. Hence the dichotomy - tie or no tie? An alternate title for this post could be:

Pick Your EA: Enterprise Enterprise, Enterprise Software, or Enterprise Technology?

With several hundred replies and counting. Kevin's Smith's challenge on LinkedIn to define Enterprise Architecture in a 160 character text message underscores one thing. There is no agreement on what it means to be an EA. Here's my shot at describing EA and the value it adds. No comment on whether we should were tie (but I do.)

Defining "Enterprise Architecture" (Again)

One of the biggest challenges facing EA is defining itself. Because EA works broadly across IT and the business, organizations should clearly understand and acknowledge EA's role. Lack of clarity causes organizational friction resulting in wasted effort and under achievement. Conversely - when an organization truly understands and leverages EA, it can save $Millions by getting where it needs to be efficiently.

Regardless of your definition, EAs are senior, experienced and costly resources. Without clarity, EA is often characterized as a bunch of highly-compensated, very experienced people who do all sorts of things that don't cohesively contribute to the business' mission. Many EA organizations have roots as a team of technology experts too senior to be placed full-time on one project; in many cases, the "Enterprise Architecture" team was established to manage this pool of very senior technologists.

Is EA Just a Group of Senior Technologists?

We get to my point and the subject of the remainder of this post: Is EA just a group of senior technologists leased out to projects or who walk around with their head in the clouds pontificating about the "enterprise"? Or is there real business value in this senior team that grew up in technology?

Since I struggle communicating what I do to friends and family; and my boss has the same struggle with his peers and senior management, I offer a definition and an example. Possibly this will help EAs get a bit more clarity on the value we offer.

A Definition of Enterprise Architecture

Enterprise Architecture (verb) - the application of proven architecture techniques to complex organizations for the purpose of helping the enterprise efficiently meets its objectives.

Enterprise Architecture, at its heart, reconciles a number of competing forces into a cohesive body of knowledge that provides an actionable set of governance artifacts in support of effective decision making.

[compare this to several other definitions on wikipedia which are also enlightening]

So, what the heck does this mean?

I did not mention technology, underscoring my belief that EA begins and ends with business. EA has its roots in technology because the referenced "proven architecture techniques" began as Enterprise "IT" Architecture (term credited to IBM) as a means to reconcile competing stakeholder concerns in complex, "enterprise class" software applications and environments.
The techniques developed in Enterprise "IT" Architecture, such as IEEE 1471-2000, and TOGAF can be applied to organizations as a whole to achieve similar benefits, document different stakeholder concerns regarding a complex organization into distinct viewpoints, and then reconcile them back together into a plan that can be governed.
Architecture is about taking complexity and figuring out what to do. It is about creating a blueprint of a future state and a plan to achieve that future state. Often this involves a definition of your current state, a high level building plan or "roadmap" and a governance mechanism.
Most important, EA produces "stuff" to help decision makers make the right decisions. Therefore if your organization has an EA team, and the products of that team are not supporting the people making organizational resource decisions, you are not realizing the full potential of EA.

Rewriting the EA definition in noun form -

Enterprise Architecture - a body of information that reconciles competing organizational forces and perspectives into a cohesive enterprise blueprint and roadmap. The Enterprise Architecture supports making the tough decisions necessary to get from where the organization is now (current state) to where it wants to be (future state) in an efficient manner. At the end of the day it's about investing limited resources in the right people, process, financial and technology changes to move to a desired state.

It is a law that I'm sure some Ph.D. has named - the larger an organization is, the more difficult it is to act in an efficient and cohesive manner manner (1). Put more simply, the bigger you are, the harder it is to move. That's where EA comes in and where the final part of this blog picks up - an example of a project with and without proper EA.

An Example

Our example involves the ACME Company that sells financial products. The company executives have established strategic direction that the company should be more customer oriented and also more operationally efficient in how it collects the money it is owed.

Sans EA, the IT planning and delivery team is likely to seize this strategy and, being planning and delivery people, come up with a very good application to deliver - a single billing system replacing 12 departmental ones, and providing a web interface to make it easy for customers to see and pay their bills on line. What could be better than this!

The idea makes the business very happy and technologists are pleased because of the technology consolidation. Initial response is so good that a project is immediately funded. Strategy and planning hand off to a project team that refines this idea into a concept, analyzes delivery alternatives, and, oh yeah, let's get those architects involved so we use the right servers and software systems to build our nifty new application.

Flash forward twelve months - the company has been unable to lock down requirements and accurately estimate the effort. $Millions have been spent with a consulting partner to define the application concept, roll up some preliminary capabilities and capture a consolidated set of requirements and define a technology architecture that will support these requirements. Successively increasing estimates to completion have eroded the originally conceived benefits to the point that the funding committee has cancelled the project. The company is not happy, technology still has 12 applications on aging technology and a significantly swollen and blackening eye socket. Some heads roll down the hallway. So exactly what happened?

Some obvious finger-pointing targets are lack of disciplined requirements by management and estimating staff. Another target is the business case and benefits estimating practices. However, even if these areas are very mature, the best possible decision would have been to pull the plug much earlier. Enabling ACME to make the right decisions so it could could achieve its goals is exactly what its EA team should be doing.

Let's look at some of the hidden problems and what EA could have done to help:

Problem 1 - there were 12 different billing applications because the company had grown by acquisition over the last 10 years. Billing and collections processes were still established and managed by departments that were responsible for different products sold to different market segments. Some were located in the home office, some billing centers operated in other locations. The Enterprise Business Architecture deliverables should have documented this current state and defined a future state in which a consolidated, efficient single billing system could operate; with these deliverables to guide, executives might have realized the extent organizational and process consolidation was needed before a single system could be implemented. Instead, the project suffered from requirements creep as the project team tried unsuccessfully to make separate billing business processes fit into a single application.
Problem 2 - Billing data was scattered across the 12 applications; the project architects understood this and the plan was to cleanse and consolidate this data into a single source of the truth. This became problematic for two reasons - first, the billing data needed to be properly coded for reporting and compliance reasons, but the project team did not anticipate the amount of organizational agreement between billing, finance and sales that would be necessary in order to consolidate 12 different coding schemes (literally 1000's of codes). Second, the volume of data created by consolidating all this billing information into a single reporting data store far exceeded the project estimates for storage and the maturity of the organization's reporting technology. Because of this, the technology architecture of the application kept changing; there were too many unknowns. The delivery date kept slipping while estimates to completion increased. An Enterprise Data Architecture should have not only identified redundant data, but also the underlying standards issues that were the root cause of the coding problems. Enterprise Technology Architecture deliverables should have identified the underlying technology gaps in reporting and storage management. All this could and should have been done prior to or at project inception by an architecture team with an enterprise perspective.
Problem 3 - The billing application estimates implicitly assumed the company's financial management systems were far more mature and capable than they really where. The business case and solution architecture were developed by the billing portfolio team which was separate from the finance portfolio; the dependencies between the systems were not documented. As the project moved through its definition phase, and the detailed requirements of the financial systems were identified, it became increasingly apparent that either the billing project would have to include an overhaul of financial system interfaces or several in-flight financial system projects would need significant acceleration and increased budgets in order to support the single billing system. Enterprise Application Architecture deliverables should have identified the current state and future state of the financial system's to a sufficient level of detail so that the billing architects could have quickly seen that the necessary interfaces did not exist.

How could this have gone differently if an Enterprise Architecture team had been available and properly functioning? Instead of handing off the business strategy to the IT planning and delivery teams to "fill the order", application of some architecture techniques to this enterprise's desires should have uncovered the problems and suggested a roadmap. To steal a bit from the Gartner Enterprise Architecture Framework, the EA should have led the business through an analysis of its Business Change Requirements to understand where business changes (organizational alignments and processes) were needed BEFORE technology could successfully deliver an application.

Wait, you say. Couldn't most of these problems have been avoided if the project team had just been more thorough in its analysis at the beginning of the project? The answer is yes; but...understanding and documenting the complex relationships between the business, data and technology is what EA, according to my definition, should be doing. That's why you have them. So if the project team had identified the business process consolidation problem as an issue, it would be doing EA! Which is great, because EA doesn't have to exist as a separate group. Continuing....

Enterprise Architecture's expertise in decomposing complex systems into component parts and identifying relationships would have enabled an understanding of organizational structure and process as it relates to the ability to deliver technology. EA's knowledge of the business would have allowed it to advise on the need to solve organizational issues before investing in technology. Similarly, the EA team should have identified organizational issues with data reconciliation and standardization as key predecessors to achieving the company's strategy. Finally, current and future state enterprise solution models should have identified gaps in the necessary interfaces between billing and finance needed to achieve the desired goal.

Had ACME been fully leveraging its team of EAs as a connector of business strategy and IT investment, it would have followed a roadmap of projects to reorganize the business of billing, establish billing data coding standards, acceleration of its financial systems projects and incorporate billing data requirements into financial systems interfaces. The EA deliverables at worst could have avoided several million dollars of wasted investment by delaying the billing project until the organization was ready for it and at best could have increased IT credibility by enabling partnership with the business in creating an enterprise roadmap necessary that move the business to better customer relations and improved management of its receivables.

In conclusion -
If you've stuck with this blog up to this point, I sincerely hope for the following:

You agree that you don't have to be a Java developer to be an good EA - in fact, the more you know about your business, the better you are.
You understand the potential EA represents to significantly help organizations get to where they want to go.
If you are an EA and have a desire to learn more about the business as a part of what it means to be an EA; or if you are from the business and all of this stuff makes sense and is interesting to you, come over to the "dark side", we need you in EA.
If you're a business or non-EA IT Executive, start talking to your Chief Architect about how EA can function as described here.
If you don't agree and you are still reading - tell me what you think. After all - this stuff is just IMHO.
If you're friends or family - this is what I do! :-)

(1) - think its burried somewhere in Anthony Kelly's Decision Making Using Game Theory, but haven't got very far into it yet.