Yesterday evening, my new Whitebook about Agile Enterprise Architecture (see here, in Dutch) got published. In this Whitebook I pointed out that developing Enterprise Architecture is a Two Way process. And that it should be build Agile.

First of all, a Business Case should be leading in the choices that are made in the architecture. This is, simply, because we look at architecture from a project point of view. A project start architecture needs to be the beginning of a project, but measured against the organization. This is exactly the problem I encounter on a near daily basis: Enterprise Architecture made too big and becoming an ideal picture instead of an realistic and facilitating process.

Enterprise Architecture basically needs to describe the Business processes, the information demand, the applications overview and the technical grounds. This is the blueprint on which we can build our system. But how can we make sure we don’t overdo it? Simple: make it Agile.

Agile Enterprise Architecture works on the same principles as Agile Software Development: the Agile Manifesto. When we understand these principles, building an architecture for our project and organization is made a lot simpler: look at the stuff we actually need right now, don’t over document the process and let people be the basis of knowledge.

In other words: Agile Enterprise Architecture is a Two Way process in which the entire group of stakeholders is leading. Therefore it starts with the basics: why do we need it. (and what don’t we need, eliminating waste.) In Agile Enterprise Architecture there is room to learn and adjust, because we don’t do everything at once, but listen to what all stakeholders have to say: what can IT learn from Business, and the other way around.

Opening up all cliches on Business and IT alignment. Yesterday, I had a discussion on how IT really could solve business problems. One of the statements that came by was that we simply needed to listen to the business in order to understand what IT has to do. This is, in my opinion, a bit too simplistic.

In the past few years we learned that IT and Business aren’t two different parts of an enterprise. Business processes are not just supported by Information Technology, but IT became part of the workflow of most organizations. Therefore the ‘you ask, we deliver’ mentality is not effective anymore. And therefore Business and IT ‘alignment’ is not a goal anymore. We need to entangle, fuse and combine.

Alignment still gives us the thought that Business and IT are two completely different things. This is no longer the case. IT became part of the Business. And only when this principle is understood, IT can become a driving force within (and not behind) any organization. As discussed in previous posts, this is the new vision of the CTO.

New technologies like BPM, SOA and other middleware solutions are based on this principle. But not always implemented. When integration of different ‘silos’ in organizations becomes pure technical, success is a guess. Determining the success factors for the entire organization (both for the Business as well as IT) is critical.

What do you think? And can you give me an example of projects in the IT domain where the success factor is a lottery?

The principles of Agile Software Development are known to most of us, but how we put them into action can be the tough challenge. At the second session I had on CreativITy at the Fontys school for Software Engineering in Venlo we discussed the possibilities to make Value the steering point within the project.

After a short recap on the previous session we started off with the dilemma we encounter in IT these days, talking about the classic Cost versus Risk model on which we use to steer our projects and where the money goes doesn’t work, value isn’t measured. Using the new insights in Agile development and Enterprise Architecture, value is one of the key points: where will the business benefit most.

During the last part of the session we discussed the new possibilities technology can offer to business values these days. How can we switch from servicing to innovation? Agile thinking sure helps here.

At this very moment I’m waiting to give one of my lectures at Fontys Hogeschool on Venlo. A long drive, so I got here early. One of the things I’m going to talk about are the missteps in Software Development, and project especially. One of these missteps is that we tend to think that we need to Predict, Guard and Control our projects in order to make them successful, while this is exactly why things go wrong.

In the classic approach to software development, we like to think that there’s unforeseeable risk involved. That we need to predict the outcome of the project and guard that change is not an issue. In this approach, using extensive Architecture, Analysis & Design and Processes like Request for Change using boards and advisories. Why is this? Do we have so little fate in our own skills?

When we take a look at what we actually are doing in a project, predicting, guarding and controlling is very strange. Because we are trying to make ideas, thoughts and vision concrete. We build stuff that on forehand only exists in the mind of some.

Thoughts and vision change during time. We gain new insights and other people share their knowledge. This is exactly why software development projects need to be based on a change facilitating manner, not trying to avoid change, or make it more difficult.

Software Projects don’t have a great success factor. According to some, this is because projects are too big, not measured right or simply didn’t have the right steer on it. These factors can all be true. But there’s more to it. Maybe even simpler. Most successful projects have been seen like a success from the moment they started. It was predefined, they where steered with one thing, vision.

But what is this thing we call vision? And more specific: what is it in a software project? A vision isn’t just one thing, it’s two: the Why ad How of your project, shared throughout the entire project team.

The six basic questions: We’ve mentioned them before. The six basic questions in analysis are essential to know where the vision may be found. The answers to those questions can, however, be different for all the actors (and therefor factors) in the project, it can only become a vision when the answer are, somehow, aligned to each other, when the entire team and all actors share the same motivation on the project.

SIx degrees of Why: This motivation of the project can be specified by simply asking ‘why?’ six times after. This sounds more simple than it is. Simply start by asking why a project is necessary, why we are doing the project. If the answer is unsatisfactory, keep asking it. If a project has a clear vision, six degrees aren’t hard. But if the project has it’s soul ‘Why’ on ‘Because’, it’s a clear sign that there it no emotional attachment to the project.

The essence of How: in the end, Software Projects need to address the Why. It’s that simple. If the technology, design or any other aspect of the ‘How’ are not clear, the success rate will be at least as bunkers as when the ‘Why’ isn’t clear.

Emotional Attachment: both the Why and How need to be emotionally attached to all actors in the project. For the Why it means that we need to search for something that all parts of our team can feel in their guts, something that makes us tick, shake and rumble. This can be something that needs to be addressed because it affects us all or something so wild, we simply want it. In the How part it’s simpler: make it cool, awesome, jaw dropping. In software development we all like to be part of something amazing.

All the above have a certain ‘vagueness’ over it. This is because it is. It’s as simple as that.

Do you have an example of a project that became a great success because both the Why and the How where shared throughout the entire team?

In recent times, everything changes. Less money available, more functionality required and competition in most markets gets harder because of pricing competition and tougher selection by customers. This can also be seen as a challenge.

Since the early 1980’s Iterative Software Development is evangelised, but still the most widely used approach is the waterfall model. Technology has taken a quantum leap in the past years, but most technology implementations are still using tech from decades ago. Software design is still done in the IT department. And the list goes on.

In the 2008 and 2009 IBM CEO Study’s Change has been identified as the mayor challenge for IT related organizations. Only to be overtaken in the 2010 CEO Study by complexity of systems. Today’s market space challenges us to create more complex and innovating solutions, in a short timeframe.

When markets get tough, creativity is the one part that can separate businesses, making sure gaining market is achieved, even in stressful times. The time to change IT strategies is right now, especially now.

In the may 2010 edition of Profit Magazine (an Oracle issued magazine on executive decisions and application implementation) Minda Zetlin (Tech-author, journalist and pro-speaker) writes a very interesting article on the changing insights in IT for corporations, and the CTO role in particular. One of the main focusses is the momentarily change from the servicing IT department, looking into ways of supporting the business, to the innovators, leading business changes using modern technologies.

Technology based corporations use this initiative for quite a while now. Looking at organizations which core business is tech-related, such as software companies or computer vendors, we learn that technology can make a difference and that the innovation in technology is their very reason for survival. But for organizations that simply use IT in order to support their business, this is a more recent change.

The progress of technology is, especially in the last decade, more and more focussed on new possibilities and innovative insight can help organizations deliver faster, more precise and in new ways. ‘You ask, we deliver’ can no longer be the statement for winning corporations.

But these new insights require vision. Simply because the road of technology isn’t paved with clear bricks and especially the creative mind will be needed to combine and create new possibilities for the market and the organization.

In her article, Zetlin states that the main difference between the modern CTO and CIO role is that the CIO has a top-down approach, looking how information technology can help business objectives and the CTO looks the other way around, how can technology push business into new directions, creating new possibilities.

There are some obvious examples of organizations that used this approach to gain more market share and new business. Think about developments like Amazon’s Kindle and various department store’s online shops. Do you know an example on how technology helped non-technology organizations forward? Created new business opportunities with vision and creativity.

IT solutions can’t be measured, or at least, it’s hard. Not my statement, but something I hear very frequently. This is, by default, not the problem we’re facing here. It’s the logical outcome of looking at the different things. We should not be focusing on measuring the outcome of the IT project, the thing we need to measure is the value gained by it. In other words, the problem. Some very relevant terms come to mind, ROI, TCO etcetera, but how do we keep focus on these element during our project? And how to steer on them?

Money is one of the simplest ways to manage a project. Because it’s such a universal language. The problem here, however, is that it’s pretty tough to measure the preferred outcome when we’re looking at the solution we’re building. But this is (for the ones who know me longer than today) a completely wrong way of looking at projects in the first place.

In IT projects we’re building a solution to a business problem, or a business challenge for that matter. These are always measurable. (In other words, if this is not the case, we probable don’t have a problem after all and we’re done.) The measurement can be pretty complex, but certainly not impossible. Look at a few variables, including labor costs, estimated loss of business, transport costs, maintenance and management. The costs are, however, always part of the problem we trying to solve.

And here forth comes value. Value, within Software Development projects, can be the only real measurable. Looking at return on invest, ROI, this is what we’re trying to do. Costs and Value can be checked off during the project and the ROI can be a good measurement for choices that need to be made.

In the book “The IT Payoff: Measuring the Business Value of Information Technology Investments” that Sarv Devaraj and Rajiv Kohli wrote in 2002, there’s a complete step-by-step methodology to assess the value of IT investments. This book lays out the basics for the modern information analysis and CIO / CTO. Devaraj and Kohli work on a basic assumption (which I believe to be correct) that the technological decisions are not in the IT department, but a joined effort and therefore joined responsibility.

When steered on value, IT projects can become much more clear where decisions are made and what type of effort is needed in order to make it a success in the organization. This also means that we actually can start making projects smaller and more efficient, because we own and share the insight where the largest profits are to be gained.

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…

Electrify! Not always a good thing, but in many projects, it might just be what the doctor has ordered. A lot of projects are just too long when it comes to really make people enthusiastic about it. So, what will make the project go ‘bang’, just the way we want it?

Add young people. This is, as many eighties series show us, a very simple action. ‘Young dogs’ in our project can give a lot of energy to the people already in it. Let the older and more experienced persons show off their skills and can give some fresh new insights in ways of designing and developing. It can take the tunnel-vision away.

Shorter iterations. Of course, obvious. But when faced with some dreadful deadlines, even the most dull project can regain new energies. Deadlines are there to keep, so everyone needs to step up.

The bell. Not always, in all teams a success, but sometimes ringing a bell can make people a bit more competitive. This can be achieved in more than one way. Not only ringing a centralised bell in the middle of the development room when a user story is finished, but think about other means. Like winning a dinner with your girlfriend when you’re the first to finish in a sprint cycle.

Are there any more way’s you can come up with to electrify the project-team? Any idea will do, nothing is too weird!