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.
]]>Most of you are either faced with a deadline that wasn’t made before year end, or with picking up the pieces after a messy year end.
]]>
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!
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.
]]>