Enterprise Architects get involved in some pretty hairy discussions. One responsibility that tends to fall to Enterprise Architecture is to steer the evolution of the business and/or business infrastructure away from needless complexity and towards effective, agile, and efficient operations. Sounds good… rolls nicely off the tongue.
In reality, EA is sometimes a fistfight.
If an EA is supposed to “steer towards a more simple future” that means steering away from the complexity that we are living with today. That means change. And with most change, someone is going to be uncomfortable. Someone is going to be inconvenienced. Someone is going to have to give up a little control or take a compromise. Someone is going to have to spend money. None of this is easy. Sometimes it is downright hard.
One trick that EA uses to accomplish this function is called “strategic alignment.” In other words, we identify the areas of the business (capabilities) that are “strategic” and then we identify applications that are “strategic” and then we start carving up or killing off the processes, systems, and corporate structures that are impeding success for those strategic processes and applications, and we add new features only to the most strategic applications. Carve and Kill. Carve and Kill. That should be our motto. Just in time for Halloween.
Why carve up and kill off? Because complexity breeds inflexibility. Complexity is the nemesis of Enterprise Architecture.
I had a manager at IBM, a long time ago, who once told me that “you could walk down the hallway of this place (IBM Boca Raton) and fire every third person, and productivity would go up.” I don’t know if he was right, but the concept has legs: fewer systems means fewer connection points means fewer projects means fewer investments. Simplicity in the system produces simplicity in the governance of the system. Sometimes, Simplicity is a numbers game, and the “strategic” application wins.
Of course, this trick works both ways. If you want your application to be declared “the winner” in the battle for simplicity, you would be well served to figure out if the application is “strategic,” and if it isn’t strategic today, find a way to make it strategic before some goofy EA comes along and suggests shutting it down.
Hence this post. You own an application. You love your application. You think your application is the “bees knees,” “best thing since sliced bread,” and “total awesomeness” all rolled up into one beautiful bundle of software. You want to protect your precious gem from that awful Enterprise Architect who keeps digging up embarrassing facts about reliability, scalability, features, and cost. What can you do?
An application is strategic if the requirements and demand for an application originate in business strategy. That’s it in a nutshell.
Saying “this app is strategic” is not the same as saying “the business wants this,” or even “the business needs this.” There are LOTS of things that a business may want, and many of them may even be needed. Only a tiny subset of what they want and/or need come from business strategy. The rest comes from “good ideas” or “continuous improvement” or someone’s commitments to their manager. Sometimes that stuff is aligned with strategy. Many times, it is just work.
There are some interesting implications of this definition. Look carefully
Find the actual words spoken, written, and disseminated from actual business leaders within your business. Ignore the trends from outside. Ignore the stuff that competitors are doing. (If you want to know why, that’s a different thread). Ignore the suggestions for improvement coming from your customers. Look at the business strategies of the business. Trace the business strategies down through your organization, from the CEO all the way down to the business person who “owns” the application. Collect all of those strategy statements. Line them up.
Now link them together. Make sure that it is clear (to you) how the organization is attempting to meet the strategic needs of the company through measurements, commitments, and business initiatives with measurable goals.
What will you see? You will see a hierarchy of strategies, one derived from another.
At each level “down” an organization, new strategies may appear that are NOT linked to the strategy of senior staff above. That is because the senior staff is assuming that specific operational imperatives will be maintained, even if they are not stated at upper levels. Just because a senior manager doesn’t state something obvious (like don’t screw with the customers), that doesn’t mean that there won’t be strategies, at a lower level, to make the customer happy.
For example, if a business has a tradition (and brand) of providing “customer-service focused” solutions and the senior leaders describe business strategies around “increasing market share in Trinidad,” the assumption is that the products sold to those customers in Trinidad increase their value through a heavy dose of customer service. In most cases like this, there is a business leader who is accountable for maintaining a high level of customer service, even if there is no announced business strategy from the CEO to do so.
So you look at the business leader that “wants” your application, and ALL of the strategies above that person. That is panoply of business strategy that motivates that person.
To be strategic, your application must be necessary to cause, support, or enable one or more business strategies to succeed in meeting their objective goal.
Find the strategy that your application ties to, and advertise that tie. Then, go to the business leaders who announced that strategy and convince them that your application is strategic. Convince them that your application is necessary for them to meet their business goal. If they agree, congratulations, your application is strategic.
Note that last step. Simply stating that your application is necessary to meet a strategic goal is not enough. You have to get the business leader who dictated that strategy to agree with you. Until they agree, your application is simply an application.
Now, wasn’t that easy?
Ran across this on the blog of Andy Blumenthal… very cool idea.
We see a lot of discussion, in the frameworks, books, speeches, and the blogosphere that discusses the value of EA as it applies to the planning and governance of money spent to change a company (usually IT dollars, but many enlightened souls will speak of a broader PMO that includes business initiatives).
As you read these sources, or listen to the speakers speak, it is clear that there is a pernicious underlying assumption, one that I would like to question.
We know that EA applies to managing change in processes and internally focused systems… but is EA also useful in helping a company to make decisions about the mix of products that they present for sale to their customers? There is very little discussion of this possibility, or how EA could fit with other processes for product development. One would assume, from the silence, that EA is not applicable to assisting with the necessary planning for products and services. I would only caution: not so fast.
First off, Enterprise Architecture includes Business Architecture. Enterprise Architects must consider all of the elements of business architecture, and if they do their job right, they work to “engineer” changes to a company to align the priorities and behaviors of company resources with the vision, strategies, and success measures of the enterprise.
When deciding what products and services should be offered, companies must consider all the same business inputs and evaluations. A Business Architect collects this data, and structures it. I’ve seen countless evaluations, and methods, for doing this work, often in a manner that structures the data for a particular report, but fails to capture it consistently for reuse. This is amazing, when you think about it, because business architectural information is the MOST IMPORTANT data that a company can consider when it plans for the future! Yet this data is frequently collected once and THROWN AWAY.
Secondly the mix of products and services offered by a company reflects the strategy of that company. The only reason that a company develops a product or service, and then markets it, sells it, provides it, and supports it, is because that product or service fits with someone’s idea of business strategy. In effect, product development is simply one elements of strategic execution.
If EA really does include business architecture, and Business Architecture can include the formation of strategy, and product development is an output of business strategy, then Enterprise Architecture can influence product development.
Yet, our frameworks and educational materials are nearly silent on this aspect of business.
I’m curious about your thoughts.
Adrian Grigoriu recently posted about the failure of EA frameworks to address real enterprise architecture, due to their focus on IT and lack of focus on business. He is right, of course, in pointing out that TOGAF does not cover Enterprise Architecture fully and that Zachman is so poor that it fails to offer any real help in solving actual business problems.
One thing that occurs to me, today, is that the Federal Enterprise Architecture effort has some advantages on commercial EA, and some disadvantages… key changes that I believe will fundamentally divide government EA from commercial EA.
First off, Federal EA programs do not need to spend vast amounts of their resources justifying their existence. The nature of legislation is such that a policy can be written in cement and that the policy can create the rationale for Enterprise Architecture. We’ve seen this with the interpretation of federal legislation to build out support for EA programs. That is a huge advantage.
Two disadvantages that will drive Federal EA’s evolution along different lines than commercial EA --
The lack of influence on funding is a key wedge between commercial and governmental EA.
Governmental EA will only ever be able to work at the micro-financing level, deciding how investments should divide up between program dollars and shared services, or clarifying the lines of alignment within a funded program. But Governmental EA will not be able to stretch the full width of EA unless and until it includes the ability to cancel a stupid-yet-legislative-funded program, or move money to an area that the government needs, in order to meet its mission, yet the legislature won’t cover it.
Frameworks evolve to solve the problems that their contributors must cope with. The Federal EA frameworks will evolve to focus on the “solution and information architecture” aspects of EA because they have no control over the formation of funding policy, only on the execution of it. Commercial EA frameworks will be able to focus on both funding and execution, and as such, will cover a broader scope with broader reach, but will spend a much greater focus on justifying the existence of EA.