Why does the business demand change?   This is the fundamental question you should asking yourself as a Chief Architect before doing any architecture work.

Many current IT strategies and architectures are failing. Senior business executives report that fewer of 25% of IT projects achieved defined project level goals. Fewer than 12% of fundamentally advanced the business strategic goals of the enterprise.  Why is this?  Why are failure rates so high?  Why should the Chief Architect be concerned?

Many IT projects are focused on the wrong problems at the wrong time.  As the chief architect, your focus must be in providing value to the business in the big picture scheme of things.  Many project managers fail to use the appropriate and prescribed methods to determine whether or not a project should continue or be canceled.

Projects can typically start to run off course because the IT department feels they should be run … and should keep running.  If we only start IT projects that are deemed to have some value to the business — whether it’s legislative changes, support of a technology refresh or enhanced business functionality, then we as chief architects have a better chance at success.

Is it possible that it is purely the project perspective at fault for these dismal numbers? It may very well be as projects that just run on auto pilot.  Without a continual review of what the original business drivers were at the beginning, Architecture Governance audits, and the lack of concern that they continue to be on check may be the reason.  It is possible that a program or project portfolio approach would lead to success?

In performing a project portfolio exercise along side our architecture planning we align that business needs and business values with the projects that are described and put on the table.  Consider a review of each project with the perspective of ranking it against their counter-parts for pure business value and business drivers and need.  Would the chief archtiecthave a better chance to attack the projects that matter to us most each and every year and provide value time and again?  It’s worth a thought.

If we also use the enterprise architecture plan as a guide post as to which projects should emerge from IT, as well as from the strategy perspective the chief architect also has a better chance at crafting the best possible project portfolio for the upcoming year.  Is there a need for enterprise clarity on the value of IT to business?

I believe it absolutely is required.   We need to ensure that the business understands the value of bringing enterprise architects and leaders from the IT to the table when business decisions are made.

Often the chief architect or CIO knows where the IT or technology can be leveraged in order to gain competitive advantage.  We also know when the business strives to achieve something that may align with the project application package solution.  Business and IT strategies have been misaligned in the past.

Often the IT strategies are driven from the technology perspective only and things that we feel we would like to clean up, upgrade, play with or tinker with.   Instead, if we align the IT strategy with the business strategy each and every year the business shall receive something that they ask for and value.  At the end of our development work they will feel that IT has served them well.

This will greater our relationship with the business and their opinion of the IT professionals installed in our organization.  We need to architect in the ability to thrive on change.  Isn’t this really what the business truly asks for and needs on a continual basis?

We as chief architects need to architect out everything that inhibits change.  We need to be weary of this when we compromise our solutions and suggesting ideas and changes back to the business.   They should not even be on the suggestion table as we don’t want a business to fall in love with something that just has nothing but havoc wreaking in their future.

If this is so important, and a critical area that we must focus on to manage volatility in the IT Architecture, is it so difficult to get buy in and involvement from the business areas. We find it difficult to get a documented strategy within our organizations, and even harder to find business resources that can be committed to creating models and providing business knowledge.

Often business resources that are committed are not given enough authority, or are taken from areas which do not have the authority to put a stake in the ground and claim that a process has been set and will be respected during system build time. Resources that are not senior executives seem to find resistance into claiming “this is how we do it”.

John Zachman has always reinforced that business activity is what provides the organization’s value chain, and modeling it is well worth the effort. We often don’t get started in the Zachman framework as the Mission and Vision statements are his prescribed starting point at the first level within the planning perspective.

Articles exist on the site prescribing some quick starts if this information isn’t available. See the newest tip, or perhaps one of the articles on this topic. The target and goals should be to answer the most basic questions.

1. Who are our customers?
2. What services and products do we offer to them?
3. How can IT support delivery of these services and products in the most efficient manners, or using technology to exploit a market niche or gain competitive advantage?

Together, these first two questions prescribe how we will deliver value to our customer, therefore providing value back to the business areas. Conversely, answering the latter two questions demonstrate how we will achieve value from the business architecture within the IT Architectures – doing the right things to create winning solutions.

Artifacts such as business process diagrams, system functionality matrices, state and activity diagrams as well as use case and class diagrams are the things we must focus on. We don’t ever seem to get here because of lack of resources, appropriate level of support and focus, nor the understanding of the true value that will be achieved.

These models will allow us to project quickly the potential impacts and reduce costs related to business rule and process changes. It takes dedication to push for resources and project budgets to adequately model these architectures, but I promise – the investment will pay for itself many times over

It’s common for me to answer almost the same questions in many different ways – it is definitely time for some food for thought about one common theme.

The theme is that many budding architects understand the basic architecture domains, and now see that the value may lie in the business architecture. Getting started is another story.

“It’s just Business”, as the saying goes, and it just seems so difficult to complete this part of our architectures. I’ve added more content this week to the Business Architecture section, and will try to keep that flow going. In the meantime, let’s put some content into this eZine.

One of the most reusable asset of your IT environment is the business architecture and the models and artifacts collected to build it. It is also the area which is most vulnerable to change, and the business rules contained within your systems and applications are the most volatile.