A common mistake that, as turns out, really needs to be disrupted: introduction of new technologies will not, I repeat, will not create Business / IT Alignment. Implementation of any new technology driven solution will, in fact, only create a larger gap between two worlds that shouldn’t be disconnected in the first place. For Business and IT Alignment there is only one remedy: communication.

When we take a deeper look into the reasons why we still tend to look at Business and IT as two completely separated worlds, we learn that it simply is a small gap introduced by common misunderstandings. Nothing technology can solve. In fact, this might be the cause of the misery.

It’s commonly mistaken that modern technologies such as BPM implementations and service oriented implementations create business IT alignment. But they won’t. They can assist in creating an environment where there’s larger common ground and help communicate about the wishes and needs organizations actually will help further. But that’s it. We still need to do the hard work.

A while ago I overheard a conversation between two very experienced software architects. They discussed a business case for a SOA implementation. It was Business / IT Alignment. Despite of their experience in the field, they didn’t recognize the pit they where falling into. But that’s not that bad. As long as the problem owner knows this. (If there is one in unaligned business and IT)

But, without being silly, how can technology implementations help us align business and IT processes? It’s easy: some new technologies will offer us a way to communicate. This all started a long while ago with analysis and design techniques and methods. Take ERD’s, UML, IDEF0. But also User Experience Design, Structured Design, SADT. And architecture visions like TOGAF. All developed to make sure end users, product owners, problem owners, developers, designers and everyone else understood each other.

This didn’t exactly happen. There are some things to blame, like development teams not working on the design and never getting in touch with end users. But Business and IT Alignment simply didn’t happen. But now things, can, be a little bit different.

Different approaches to software development, like the largely popular agile software development method Scrum and models that can actually be executed, like the new BPMN 2.0 specification, just might make the difference. Less translation, less interpretation, more communication and more cooperation. 

Sounds like a solution.

When talking Service-Oriented Architecture, technology is quite often the thriver behind the discussion. Why is this? Isn’t focussing on services and process orchestration enough food for thought? In other words: does it matter what happens underground?

Okay,  not completely correctly formulated. Of course we need to know what happens underneath the processes and what the technology is all about. What I’m pointing out is the following: SOA solutions tend to be seen as a tech-driven, non-functional element in our infrastructure. Not as a business driven solution.

Besides this, a business case around any SOA project can be easier maintenance or something in that area, but it rarely is. This means that we cannot focus on technology benefits of SOA transitions, but only on the business value it will create. If it can’t be found, don’t do it.

Now we get to the point that is services transition: the transition from silo thinking (which is something completely different than, and cannot be confused with, application / system thinking) towards services. Service is, according to dictionary.com, an act of helpful activity. It’s as simple as that.

This is the largest transition for an organization to encounter. Creating an internal apparatus that offers the end client a one-stop shop. How they get their information doesn’t really matter. What happens underground neither.

When looking at SOA implementation from this point of view we can put the technologies we use, like the Oracle SOA Suite, in perspective. It is possible to go services oriented without the SOA Suite, it only helps us achieve our goals.

Business and IT working together is supposed to be a tough challenge. But why? Is IT that complicated that we cannot make the end users understand what their gain in it will be? Or is it that we simply can’t make ourselves understandable.

Both.

As I said earlier, Business and IT alignment isn’t a real-live (or even existing) problem. It’s simply a matter of jargon and deep knowledge based issue. It’s common in all knowledge and experience based professions. Take a look at the doctor that can’t seem to make his patient understand what’s happening within his body, the car mechanic who overcharges because I can’t understand a word he’s saying about the troubles with my car. It isn’t that IT specific.

So how can we make ourselves understandable? Simple: communicate. And know what your jargon and own knowledge is. Once we understand those principles we can get the Business to understand us. And in the future we might even be able to understand the Business…

In April I wrote a blog post on what books I highly recommend reading. It was because I just had a great session at Fontys Hogeschool about Software Development and Business Alignment. Last Saturday, I had an awesome talk to some very creative people about what really does thrive Business & IT Alignment. (And if it actually exists, as a profession). During this conversation, we also mentioned books. And now I realized that I’ve never shared them with you.

Enterprise Architecture As Strategy, Ross, Weill, Robertson. During the Oracle Enterprise Architecture Executive Summit, Jeanne W. Ross explained how Enterprise Architecture could create a more sustainable and agile business environment. The MIT scientist explains how the Business and IT parts can move together and actually add value to the complete organization. A few things that I’m really glad about is the fact that the books states that Enterprise Architecture is a journey, not something that gets implemented overnight. As well as the fact that EA isn’t about risk and documentation, it’s about facilitating agility within the organization.

Business Model Generation, Pigneur, Ostenwalder. Co-created with over 470 professionals all over the world Business Model Generation provides us with a simple, yet effective, method on how to design a new business model. A few things in this book apply to everything we do in the IT field. It basically is the complete reference we need to build our Business Architecture. When taking a look at the way the business models are generated in this book, there’s a lot of conjunction with my own method to create a ‘talking picture’ (anyone: is this the correct phrase?) on IT projects. A lot of visualisation to help communication and outlining the needs of the project.

SPIN Selling, Rackham. I like simplicity, and this book offers it to us. Looking at the SPIN selling method, written down by Neil Rackham, it gives us a simple, yet effective method in knowing where the ‘Why’ is in the projects we do. Situation, Problem, Implication and Need Pay-off are the basics in information analysis. I’ve written a post about it.

Business / IT Fusion, Hinssen. The best book written about the concepts of alignment. (Although Peter Hinssen shows us the concept is non-existing). This book gives us completely new insights in the way IT has changed, or should change. Will not go further in the matter here, but it definitely is a must-read.

Enterprise 2.0, McAffee. When we take an in-depth look at one of the most common challenges in IT and Business these days, we look at user collaboration. In this book Andrew McAffee gives us insights in the benefits large enterprises can gain using this technology boost. A fun read and shares what new technologies and principles can actually give us.

And then there is, of course, the brilliant book Oracle Application Express Forms Converter, van den Bos.

Are there any other books that you recently read (or a long time ago) that would give us new insights in Business and IT?

Business and IT Alignment; a bright idea that isn’t simply put into action. Making IT and Business work together towards a better organization or better results is, somehow, a difficult task. (Hopefully, you think is very strange, as I do). As IT is part of the Business we should all work together, in one team with one objective. It’s all the same package. Even better: IT within the organization is a one package deal.

Looking at the outcome of various discussions I had the past few months about how to make sure Business and IT work more aligned to each other, I’ve learned that it’s a non-existing problem. Business most often explain that IT is an essential part of the overall strategy, IT tells us that Business objectives are always the driving force of their existence. The only thing both ‘parties’ agree upon is the fact that communication and understanding of challenges is difficult.

So communication seems to me the only part we need to tackle in order to create a sustainable relationship between these two parts of the organization. Over the years various tactics to solve this issue have been tried.

First, there was the information officer, then the technology officer became a common role within organizations (even non-technical ones). Second we developed and implemented intensive programs to force communication and to direct outcome. But did this help?

Not exactly. The various programs and official chain of command created an environment of non-trust and directive, forceful communication. Therefore creating exactly the opposite of the intended outcome. The keyword here is trust and vision.

In sales there is a great saying. If you can’t tell what you do in thirty seconds, it’s not worth it. But the elevator-pitch is true to all parts of business, not only sales. Maybe thirty seconds isn’t sufficient, but we should make things more simple. Just talk to each other. But that’s the hard part right?

If we look at Business and IT as one and the same, one package, we can make this less hard. We have to talk the same language. If words create confusion, because of jargon, we simply will reach for other methods. Draw, play, sketch. Everything’s allowed and if it helps Business and IT working together, we should.

“show me the money…”. One of the best films ever made. But what does it have to do with IT? Or with Business and IT alignment? To be completely frank, everything. One of the main things that grasp me every day in my line of job is the total neglect of Business Case value in the projects I encounter.

Is measuring the value of a solution essential for the path that we choose? Yes it is. In the modern days, say somewhere since 2008, we have no choice but to have a clear view on the expenses and gain on every project and IT solution we offer towards the business. Although some organizations gained a tunnel vision on cutting costs. They actually have a point. But they shouldn’t look to just the costs of the project. But also to what the organization will gain from it. Where’s the value?

Measurement is everything. You might not agree. But it’s the most simple thing on earth to know if you’re doing a good job. In IT projects it’s not different. And the most global understood and recognized measurement of all is money. It’s that simple.

Terms like ROI, Business Case and TCO suddenly jump to my mind. But I think it’s more simple than that. When looking at IT projects and the way we govern them we should look into the gains versus costs of the project. Within the iterations that we work in. 

What does the performance of our system cost us in lost revenue? How many customers do we loose if we don’t get ahead of competition? How much money is to be gained in the clear objective of this project?

And more if you think about it. 

Now to the quote you can all kick at: “If we can’t measure it in hard nickel, we will never be able to get it done.”

What do you think? Is money everything? 

If you believe a lot of marketing around Enterprise Architecture it is. But in the practice the overkill of EA strategies and implementation really brings a lot to mind when it comes to solutions on Business and IT misfits. IT doesn’t support Business as much as it should. IT doesn’t push Business as hard as it could.

But where does the problem lie? Probably in the simple fact that, although, Enterprise Architecture tends to focus on infrastructural issues and application challenges instead of focusing on Business Architecture and the goals and challenges of organizations.

Besides this, there is a bigger issue at hand. Enterprise Architecture’s main implementation within organizations is to avoid and address risk within large enterprise IT projects. To make sure the project will have the right focus and responsibility is taken in account. Not to support Business / IT Alignment. Because of this, EA has the tendency of becoming nothing more than a ‘must have’ documentation strategy. Instead of real added value.

Too bad, because the right implementation of Enterprise Architecture, using a creative, pragmatic and agile approach, really can be a solution for non-performing Business and IT strategies. The proper way of looking at EA is, in this case, not a risk manager, but a facilitator to change.

On Monday September 20th, I will attend Oracle’s Enterprise Architecture Executive Summit (gee, that’s a long name…). One of the breakout streams is on the topic of ‘EA and Business Alignment’. I really do hope that we (finally) start talking about agility in Enterprise Architecture instead of control and management of pre-defined outcomes.

In my humble opinion (which everything in this blog is actually about, my opinion) Enterprise Architecture has the possibility to drive Business goals and facilitate change and agility. But the main question remains: are the present Architects able to change themselves?

(Disclaimer: It’s not my intention, nor is it ever, to offend or make fun of anyone. The above simply states the notions I have during my work. If, in any way, you disagree or feel offended, please let me know.)

Although most of us realize that projects need to get smaller. Actual small IT projects barely exist. When we look at integration and migration projects. Designing new Business processes and aligning technological solutions to mach those, we open a large number of organizational challenges.

Especially integration projects can contain a lot of misconceptions in the organization. In what domain do we actually work, is it IT of Business? The main focus should be on the Business Case for the entire organization, not on the benefits for the single actors within the project. So, here comes the question: what’s in it for me?

When we don’t share the knowledge of the Business Case with the different actors we will create an unsustainable environment within the project. Resulting in a situation where all parts of the organization (in large integration project, we always touch more than one part of the organization) only bother with the impact on their own domain. Ambiguity kicks in.

When decisions in the project aren’t gathered and shared throughout the entire group of involved actors and parts of the organization, these decisions will not be understood properly. Therefore the entire project will create a conception of top-down forced scope. Nobody will be your partner when this is the general feeling within the project. And we need those people.

Therefore it’s absolutely necessary that we all share within the project. Large integration projects have their impact within the organization and change is scary. Even though we do it with the right intentions, it will not be felt this way.

Then. What is the solution to this? Simply create an open en interactive environment within the project. Share knowledge and perception. When all actors get their focus right (which only works of they have the feeling it’s their own focus) the goal of the project comes in sight. For all involved.

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!

Oracle’s OpenWorld conference sure looks promising this year. Lot’s of insightful, technical in-depth sessions and personally I’m looking forward to what this years keynotes have to offer. Great new stuff? More integration of Sun and Oracle products? (It’s the first OOW since the acquisition got official.). Today I decided to offer some input in the developers power myself. On wednesday, September 22nd, at 9 am (I know, the morning glow…) I will present my CreativITy session in the Mason location at Hotel Parc 55.

This will be my third Oracle OpenWorld in a row. And although there are always very interesting sessions about (new) technologies to be found, there are almost no sessions that actually inspire and create new insights in software development.

I will try to change this during the CreativITy session on wednesday morning. CreativITy is a creative approach to software development. I’ve done this session at various places, like at the Leiden University and Fontys Hogeschool. Inspiring and tickling developers, changing the way they look at software development and delivering value. This session will be focussed on Oracle and Java developers.

How can we actually use all those new technologies presented at OOW to our (and the organizations’) benefit? And in what way can we make sure technology will thrive businesses? Become more than ‘just’ a developer and put some CreativITy into your precious work!

(note: according to the Pinceton WordNet dictionary ‘Creativity’ actually means ‘the ability to create’. Therefore all software developers are creative people by default.)