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?

Two large new releases by the Oracle Corporation that I’ve written about the last few days, Oracle Application Express 4.0 and Oracle BPM Suite 11g, got me thinking. The one focused at delivering Web 2.0 interfaces in an extremely short amount of time, the other on combining static business processes with Enterprise 2.0 capabilities. What will happen when we combine the two?

Oracle Application Express came a long way from simply developing Database applications. APEX version 4.0 gives us a wide variety of additional feature in order to really combine the fast delivery of applications within a Service Oriented Architecture, SOA. Building an APEX application on top of web services isn’t new (we’ve done it before), but with APEX 4.0 it just gets simpler. REST assured.

This means that the days that APEX will only run on data that’s inside the database are really over. Of course, this is still (and will be) the main implementation of the tool. But we don’t have to anymore. Web services will give us the possibility to combine data from different sources and finally give end users a real interface on their business.

Looking at the power of Oracle’s BPM Suite 11g, we can also model these web services according to the business process that it will support. The combination of the two would mean that we can give end users a personalized web interface on their own business processes. The BPM Suite (read: BPEL and OSB) will provide the APEX application with relevant data and authorization on that data.

Think about it: a universal interface for the business, changed and developed in short iterations, that provide access to data based on the role of the user. Managers that get insight from the progress of certain processes while, in the same application, the sales manager uses data from his sales management application and CRM. Think about it.

Combining the two Oracle product will give us a much appreciated combination of complete application integration, modeled business processes and interactive and intuitive web interfaces. What other large possibilities would you see?

Yesterday was a great day: Oracle Application Express 4.0 got released. But not a great night. At least, if you measure nights in amount of sleep. The new Oracle software is so impressive and extensive I wanted to play with it all night. And why?

Because I fell in love with it all over again. Some of the new features in the new release of Oracle Application Express are so well formed they really are a lot of fun to play with. The developers’ interface is very well rewritten and gives the developer a lot more ‘sense’ to what he is doing. This makes developing in APEX even more fun than it already does. I’m really looking forward to be doing my first extensive development project in Application Express to get a feel of what this Team Development is really about.

The new templates in Oracle Application Express are the bomb. They offer much more capabilities to the end user than it did before and, in combination with Dynamic Actions, we really can develop something that has the end user in it’s main focus. User Experience entered the world of Oracle Application Express big time.

Looking at the new software I really do believe that Oracle Application Express got a whole new focus. Where in the first years the main focus was on Access migration and simple departmental database applications, we finally evolved to a full grown Rapid Web 2.0 Development Platform.

Where is the main focus shift in Oracle Application Express 4.0 according to you? And are you as much in love with it as I am?

Since some years the Rapid Application Development platform of Oracle, Oracle Application Express, has gained more and more fans around the globe. I like it, and so do many others. Since today the new main release is available on the Oracle Technology Network for download.

Mike Hichwa, vice president of Software Development at Oracle, calls it the most significant release yet as it adds more features than before and it pushes the platform far further than previous releases. And it does. APEX 4.0 really kicks the functionality and therefore business value to the next level.

Web 2.0 is the main focus on this release. Offering various improvements for both developer as well as business users. Dynamic actions are the real deal. Offering end users great desktop-like functionality without the hassle of developing complex JavaScript and AJAX. This means that we can deliver more functionality to the end user within a shorter amount of time.

Where the 2008 3.1 release of Oracle Application Express offered the great new functionality of Interactive Reports to us, creating a way where end users could consolidate and order information themselves, End User Computing takes a quantum leap in APEX 4.0 with the new ‘Websheets’ functionality. Websheets offer end users a web environment where they can adjust, create and read data within a group of people, with no development needed.

End users now can really become part of the development process themselves. More examples will come to you in the next couple of days. If you haven’t already: download APEX 4.0 from the Oracle Technology Network now.

Today Oracle will release it’s next generation in Business Process Management, the BPM Suite 11g. One of the things that stand out, at least in buzz words, is the fact that it supports something called ‘Social BPM’. So what is this and what will it do for the business?

In one of the Oracle BPM WebCasts, Dan Tortorici and Peggy Chen, respectively responsible for BPM and Enterprise 2.0 Product Marketing, tell us where the bridge is to be found between Enterprise Collaboration and Process Modeling. The new approach shows us how to create an Agile framework to facilitate fast changes within the organization while effectively combining formal workflows with informal collaboration.

In traditional application environments, we think in ‘silos’: separated departmental systems that contain specific information. Business Process Management and SOA approaches to architecture helps us to combine those data and effectively create a flow that supports business processes that depend on multiple silos. Using this approach we can steer on the process, instead of information and data. When we take a deeper look inside these processes, we learn that there is one more element missing: ad-hoc changes to the process, human interaction.

In the ‘classic’ approach to BPM human interaction is merely a task, what the people do behind the buttons is merely described as an action, not a process. And this is where collaboration and user interaction comes in. Using the possibilities of the Oracle WebCenter Suite, Social BPM focusses on combining business processes and user interaction.

Working from a user centric design model, Social BPM offers the possibilities for the end-user to create, monitor and participate in business processes, al within the WebLogic Collaboration Suite. This new element in the Enterprise 2.0 philosophy adds an enormous, in my opinion, breakthrough: we stop using information statically but combine the dynamic of user interaction with the structure of Business Process Modeling.

The User Experience is now total: we have insight in our dashboard on the complete process, which participants we have, what information needs to be combined and where our process is headed. This gives us, possibly, the ultimate user interface on business applications. All data needed to effectively proceed in the business can be combined with the process, which can be modeled within the same user interface.

Today at 19.00 CET is the official launch of the Oracle BPM Suite 11g.

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.

“Fear and Complexity within a project, can be an explosive mixture that makes sure any project can fail.” According to the experienced agile project manager Martin van Borselaer Fear and Complexity are the main project killers. “Fear restrains us from doing or saying the things we know are right”, Martin says during a great session he gave the company last week. “It is, in combination with complexity, the main reason projects fail.”

Fear, from the different actors within the project, can have different sources. The customer can be afraid that the project will cost too much, the quality will be bad or that he works with the wrong requirements. The supplier has it’s own fears. Under budgeting the project, dissatisfied clients, damage to his reputation or unsatisfied co-workers. A project manager can have fears like a bad functioning customer organization, team or technology he has to work with. And the team member is possibly afraid that the balance between his private live and job comes into question.

“There are also deeper fears to consider within a project” Martin tells, “you can think about things like the livelihood of the employee, loosing his job, not making promotion”. ”Or more emotionally based fears like the ego or status of actors in the project” Martin explains. “Fear is a very bad advisor in a project situation. It can offer a excessive reaction by making problems larger than they really are, or no reaction at all by denying the existence of a problem.”

In projects this can mean that we work with fixed date, price unknown scope projects, excessive analysis and design or not being able to grasp reality and therefore sticking to the original plans without necessary adjustments. Martin explains that most of these examples are based upon actors being afraid, offering false hope. Working together, not looking at the team in terms of heroes and losers, is an essential part of the solution. Transparency in the project team will facilitate mutual trust and therefore a real team where fears can be tackled.

Another project killer is complexity. “Simple is Stupid and Smart Sells are main criteria these days in IT projects. Or, at least, it seems to look that way” Martin says. “The assumption lives that we can control and predict this complexity, but the reality is that we can’t.” Martin explains that, during the start of a project we don’t know what we want and that we don’t know how to get there. Working together and steering on new insights is the only way of getting on a point where we want to be.

Working together, small steps and learning and improving are essentials to tackle both fear and complexity within a project. Organizations that know that change is to be expected and understand that steering constantly is normal will have the competitive edge. It’s essential that scope is put together on functionality, not by expertise. Bringing together expertises will reduce fear and complexity. Or at least make them more understandable. In this way we can actually manage them.

Martin van Borselaers blog is a very interesting place of knowledge on Agile project management, you should read it.

UPDATE: Martin now offers a once in a lifetime opportunity: you can get his advise, for one day, for free! So if you want to have a fresh look at this project of yours or more information on how you can do things different or even better, look on the (Dutch) Whitehorses website for more information.

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?