1. CEO’s Top Strategic Drivers
2. CIO’s Primary Concerns
3. Enterprise Portfolio Management

In fact, the CEO owns, knows, eats and breathes their top three strategic drivers.  At a time in the economy that we are facing now pure survival may likely be their number one focus.  Such drivers might include the area cost savings, as well company stock prices.  The chief architect needs to fully understand how these drivers impact or are impacted by the Enterprise Architecture Plan.

Figure out plan of attack

Choices made in the areas of infrastructure and solutions will most likely be efficiency based, and risk averse.  Creatively considering ways in which the architecture can contribute in the area of competitive tactics is another way in which we can provide value.  If the CEO is really focused on their competition’s moves, it might be a looming takeover or collapse.  How can the strategic plan allow for agility in these types of circumstances?  What would it take to expend with a line? A division?  Or purchase either?

An additional area of CEO concern is major projects.  The CEO realistically needs to keep aware of the biggest corporate expenditures and these may be IT projects.  Characteristically these are very high profile projects or large replacement projects.  The chief architect should be fully aware of what the CEO’s concerns are, and what it is troubling them about the projects.  It may be the board’s opinion of the project, or where else the money could be better spent.

The second area the chief architect needs to focus on is the concerns of the CIO.  It is crucial to have a list of things that keeps this soul up at night as well.  Some risky hardware component or some recent security lapse could be top of the list. It might be an employee or staffing issue.  Where they are privy, the chief architect needs to explore what can be done in upcoming plans.

Ultimately there is the major issue of job retention as a CIO.  Budget cuts and less than stellar IT performance can be used as stimulus to look within the large resource pool available.  What can be done to ensure IT performance is not a factor.

A major area of concern to the chief architect should always be enterprise portfolio management.  This is the prime source of where strategic future directives will be exposed.  The architect needs to comprehend and be fully aware at all times of the biggest opportunities.  What was the biggest project or investment identified?  What is on that list or that requires the biggest investment AS WELL as the biggest return on investment.

I would suggest that the chief architect to quickly scan that portfolio management list on a monthly basis and retain a list of the quick wins and low hanging fruit.  Each of these should be incorporated into whatever future planning is being pursued as the opportunities are available.

You’ve got to keep the pulse on these critical elements – and keep this in on your laser focus.  Continually update your enterprise architecture plan where you can whenever these strategic drivers change.

Happy Architecting

Sharon

Approaching IT projects from purely a project perspective is essentially a flawed method – we need to see this from an enterprise portfolio approach. Seeing solutions from the perspective of adding value to the business as an asset! Combinations of architecture initiatives and project portfolio planning are currently considered to be winning solutions.

The signs and symptoms of fundamental change to IT are that budgets have been trimmed. The amount of time to plan projects has been reduced, and critical investment analysis is frequently done on all business expenditures – including IT!
Business competition is fiercer than ever because of the most recent focus on the niche. Companies are selling off
non-core competency pieces of their business, outsourcing some of these operations and narrowing their scope.
What’s this got to do with Architecture? There is a demand for faster response to change. Critical issues to the IT
department are:

* Mis-alignment of business and IT Strategies
* Primary focus on one project at a time
* Adhoc request fufillment
* Lack of enterprise clarity on the value of IT and consistent and disciplined use of technology

In order to provide a quicker response to change, we need to provide a more agile architecture environment. Traditional IT delivery processes have failed. Adaptability really equates to risk management for business. It’s a very tough sale to the business side of organizations that money should be spent on designing a flexible architecture.

Over and over again I tell clients that if they can’t get buy in for architecture programs, it has to be done piece
by piece, with continual communication and publicity to the winning attributes/benefits of an architectural approach.
The business process cycle times have collapsed, and now more than ever, architecture is the answer to responding to change and reducing project risks.

So what does this mean to you the architect? With each and every individual project you embark upon, keep this in mind: architect in the ability to embrace change – architect out EVERYTHING that inhibits it. If that means choosing an application integration strategy as one of your architecture components, one project management task must be budget approval of that piece.

If you are faced with the lack of time to convert and migrate data, and interim bridging strategy must be utilized so that as new projects are undertaken, the data change impact can be localized and each project can attempt to include the change to the legacy data stores.

If you wish to phase out a technology and standardize on a prevailing one, restrict the use of the old and find ways to encourage the new. If the technology you require to respond to business needs is immature, ensure that you
architect IN an easy exit or transition strategy – if you’ve got to pick one now – ensure it won’t be really painful to change it later.

Architecture tip: When constructing your architecture strategy, proactively include a focus group or meeting with key business stakeholders. Ask them: what is the most likely change to your business in the next 12 months?
18 months? 2 years? The answers may surprise you, and likely will give you hints and signs of what kinds of change you are likely to encounter and must architect in!

The following describes a scenario in which the Enterprise Architecture may be leveraged for pure business benefit:

A snippet from one of our case studies at Firefli Consulting Inc.

Eventually, we decided to reorient our architecture efforts toward providing the context and facts to guide planning decisions. But first we have to do some work. For example, if an IT department already has a well-defined technical architecture, but was focused on technology and tool standards, IT may have little connection to business applications. To supplement it, we might develop several architectural deliverables.

* A model of the business that identified key processes, constituencies and business capabilities.
* An inventory and map of the current state of our business application portfolio. We then overlay that on our current technology infrastructure.
* A target state for the business application portfolio.

With these in hand, we can engage in the next year’s annual planning process. We can map the proposed projects to the business model to see how projects related to each other. That allows us to identify project overlaps in terms of common or related business functions, such as data marts with a high degree of common information.

When it comes time to prune the list of proposals, we could suggest consolidating projects so that one single effort could support more than one business need. The overall economics of the consolidated projects is improved-more business benefit for a given unit of investment-and so was their priority for funding. IT resources could be focused on a smaller number of projects, resulting in higher quality and more reliable delivery, as well as a reduction in subsequent application maintenance.

Similarly, we might uncover many situations in which business areas are proposing projects that overlap with applications already existing in other areas. Because our IT groups may work in silos to some extent, they would not have been aware of the redundancies. We can now identify those cases and recommend either building on the existing applications or slating them for replacement.

Our architecture approach can allow us to proactively assess the fit of proposed projects with the current technical architecture and provide early on a critical heads-up of the risk or cost that will be involved when the fit is not good. Software upgrade plans, meanwhile, can now be compared with the proposed projects to see where they could affect a project’s timing or the cost to perform the upgrade. The project’s estimated cost is then adjusted to reflect this.

It was fabulous to see the look on her face when I explained that there had been many talks to integrate with such a service, and since the decision had been not to, it was not lost. You see, there were business implications in integrating the service, and while the business did not dismiss the objective as impossible, they said “just not right now”.

We have to include design for such possibilities, even if we don’t have all the plumbing installed at the time.

It’s an exciting time in both Enterprise Architecture and IT architecture in general, as SOA continues to build momentum and gain respect as more than a silver bullet.

I cover the topic Service Oriented Architecture extensively in both the Enterprise Architecture Boot Camp, as well as an upcoming one day workshop “The Service Oriented Architecture Boot Camp”. For more information, see the training catalogue.

Give the Business What They Want!

Last week as I was shuffling my IT magazine pile looking for something good to read, I came across an editor’s note in EDGE Magazine that validated something that I’d worked on very recently. As enterprise architect’s, we are always trying to be validated, justify our projects and sustain funding for the next wave of what we hope to be the path to goodness.

The article stated “Ask any CEO to name the very top items on their agenda and the conversation invariably turns to “innovation” and “transformation”. As any CIO to name their very top things on their list and they will tell you its “information” and “technology.” “

Previously I ran a workshop at a PMI conference called “Optimizing the Program Portfolio” that reinforced some of these same beliefs. The crux of it all was that if we were to carefully plan and plot our course of programs with both our assets and proposed projects in mind, we should maximize efficiencies reducing budget and time resources spent on running the business. This in turn, would make more time for transforming the business.

It seems like a simple feat, but this is more complicated than one would think. Program Management and Enterprise Architecture are so very deeply intertwined that one should hardly talk about one without the other. It seems that we never get past choosing a framework, cobbling together a strategy and then completing the first few models and maybe a set of principles. Beyond all of this is planning for transition.

There will be so many projects that need to be planned and executed in order to get an actionable enterprise architecture, that we will likely be overwhelmed and unable to get even the smallest percentage done because of ongoing operational and infrastructure support projects. It is important that we carefully time and plan what will happen next so that in the end we are making more time for the things that CEO’s have on the top of their lists.

Often we do our CEO’s top priority, but at the expense of our operational needs. We are in a rush to bring in silver bullet solutions, excess resources, and cut in-progress projects because they aren’t on the top of the list. Sometimes, we need to push back, ever so slightly on timing only to ensure that the infrastructure and architecture can support these transitional projects.

On the other hand, we need to expedite these projects, and keeping an eye on our top priority has become easier now that we have the attention of most in the organization. Services oriented architecture is most likely not just flavor of the day, and we are apt to find support for infrastructure and architecture projects that will support it.

So where does the portfolio management story fit in? We must take a look at our top three priorities both from an IT perspective as well as a corporate view, and determine the best ordering. We should look at what we have (our assets), leverage them as best we can, and then view our gaps and projects on the books to come up with a portfolio that will make both the CEO and CIO smile.