I’ve never met anyone who loves think, extensive reports, not even for their essential strategies. But we still create them. Why? Because we think it’s important. Working out the first steps in Business & IT strategies is essential, but we need to brighten up a bit.

Lean and Agile thinking works on this principle. We need to facilitate change, but create a good end-product. In ‘the business’, we know that this means that we should try not to predict the outcome. Simply point out the vision of our project. Business & IT strategy is not different.

Visualize the goals and vision we have has a lot of benefits. Within a group session we can, together, determine the outlines of our project. This means that we have the possibility to create a group feeling about the strategy we want to walk. The benefits we will create during these sessions and the visual sketch we create can be summoned in the following:

First, we facilitate the dialogue. The strategy sketch will serve as a reference point. It’s simple to understand and will create a shared language in the strategy we aspire.

Second, we can explore and trigger bright ideas within the entire project and strategy group. We can play and inspire new and exciting ways of looking at the organization and the technologies that are forehand.

Third, it’s a way to understand the essence of the strategies and projects we are developing. Pointing out the 7 basic questions (yes, wait for it… I developed a seventh basic and essential question, more of this later) we learn what’s important and what’s not. This helps us making choices during the project and the workout of the strategy finally can create more value.

The fourth, and probably most important, it gives a boost to the communication within and without the (project) organization. It makes stuff simpler and more interesting and inspiring to work with. Picture really do say more than words.

To put it simply: the right model makes sure we play on common ground. All involved actors can work in the team developing the rough outline of the strategy and the vision for our project. This means that we, finally, all can join the game. Instead of creating a vision on top-management level, or developing a project plan in the IT department.

Currently I’m working on improving this model with all the excitement that comes with it. I truly believe in this way of working and would love to have the opportunity to develop it further. I’ve used the Business/IT strategy canvas (in Beta) in some of the projects I’m involved with now. But it would be great to see if it works in different settings, and improve it even more.

Would you like to test-drive the Business/IT Strategy Canvas, together with me, in your own project? Let me know in the comments or contact me and I’ll surprise you with its effects. Thanks!

Looking at Software Development projects and the strategic implementation of this into any organization, we have to take three pillars into account. Technology, Policy & Management and Analysis & Design. All these aspects can make sure the build software will have an sustainable character and really adds value to the organization. But where do we need to keep our focus on?

Technology. The Technology pillar is the start of it all. Where Technology can actually add extra value to the organization and create a climate of support to additional demands and wishes for the business. Technology, however, can never be leading within the development department, business processes and their value have to be. Within an IT department that works very closely to the rest of the business technology can become a ‘driver’. Thriving the enterprise because of the possibilities the technology offers, this is a main role for the IT department and the responsibility becomes clear; work together. Technology strategy will focus on maximum results, with a minimum of effort, with the assumption to create a sustainable environment where business can keep focus on what they actually need to be doing and IT helps the business to meet objectives.

Policy & Management. Any IT project has to be managed and has a strategic policy attached to it. In order to define the policy concerning Software and IT Projects, we need to visualise the objectives, challenges and difficulties the Business we’re in are facing. The policy simply has to be clear and simple, no need to make thing more complicated than they need to be. Policy and Management are the direct results of business vision and therefore not in the IT domain. But it’s teamwork between the IT department and business.

Analysis & Design. To determine the value within the project and in order to make sure we grasp and deliver this value to the business at the end of the project, we have Analysis and Design. During Analysis we look at ways the policy can be matched to new business objectives and (or) business challenges (ne need to talk problems here). At the Design stage, not necessarily in this sequence, we determine how the Technology can support the policy. Analysis and Design are the main translations of the Policy & Management boundaries, mapped to Technology, to the challenges the Business has at this point.

Policy and Management are the layers we build upon, Technology and Analysis & Design are derivatives of the policy and the way we decide to manage the projects. Analysis & Design are, however, direct results of the made policies and the strategic choices we made on Technology. Strategic choices on the three pillars we mentioned above are measured continuous on Cost, Risk, Quality and Agility.

The coming period I will discuss these pillars, and the way we achieve them, with you and various others. Here on Ome-B.nl there will be more structure on topics related to these challenges. Or, how can we come to a customized and tailor-fitted strategy on Software Development?

Note: The image above is a detail on the Oracle logo, but Strategy doesn’t necessarily need to include Oracle’s Technology Stack…

We have discussed the must of Business and IT working together, enabling instead of passively facilitating. We have talked about Enterprise Architecture and an approach where it goes wrong and just becomes an documentation obstacle and a way to ´hedging´ for the IT department and why we need to set a measurable Agility parameter inside the Architecture process. But in what way can we make sure Enterprise Architecture simply becomes a part of Business Strategy

There are several studies conducted on the matter, where the work of Ross, Weill and Robertson is very noticeable, where the Enterprise Architecture is mainly portrayed as a way to make business strategy possible, or as a part of business strategy. None of the studies I´ve seen show how or even if Business Strategy can be the outcome of Enterprise Architecture, more than a facilitator or a profile in which Business Strategy can evolve. (do you guys know any other studies or examples of this nature?)

In previous posts on the topic I made the wrong assumption that Enterprise Architecture was in fact an activity within the IT department, and therefore I contradicted myself. These things should never be in the sole propriety of IT, but a mutual adventure for the entire Business (including the IT department). But there’s also a change that this happens too much. Is this the reason why EA in the real live becomes an overacted documentation stream?

When we take a look at the title of this post, Enterprise Architecture as Part of Business Strategy, I come to think that in real live it’s the other way around. Business Strategy as Part of Enterprise Architecture. When Agility becomes one of the measurements of Enterprise Architecture it would be possible to create a both-win situation. Where the overall Business Strategy really gets input from the Enterprise Architecture and where Enterprise Architecture actually will help the overall Business Strategy. Your thoughts, please.

IT projects are in the IT domain, just like Marketing projects are in the Marketing domain. Makes sense right? No, it doesn’t.

When we take a look at IT projects, we need to understand the fact that the only right of existence is the fact that we support business processes. This means that we need to support and suffice the processes that make the business run, makes them tick. Any IT project is only a way to support a goal, we don’t make the goal, we don’t reach it, we just pass the right shot ahead.

The days that we thought that we understand the actual processes, problems and challenges the business is in, need to lay behind us. Think of it as: ‘we just don’t get it’. This isn’t a bad thing, it’s a good thing. We are good at IT, not at running the entire business. Yet we tend to pretend we are.

IT projects that mainly lay within the IT domain usually go bad, this is because the wrong people try to model and fix business problems and support business challenges. If we take out the responsibility out of the IT domain into the actual business problem owners domain, the right decisions can be made and progress is more eminent.

This strategic choice means we need to get focussed on what we do best: IT. And the business can focus on what they do best: business. This results in a way of working that is much more efficient and pragmatic. We can actually help the business to achieve their goals.