Agile. Within the Software Development business we look at the principle mostly as a way to deliver functional solutions to the business. Agile Software Development. But rarely we look at the solution itself to be agile. Is this the right way to look at our business? Isn’t the solution itself the highest goal? (Which, in my opinion, is the most important principle of the agile manifesto).

When we look at the solution itself offering agility to the business, we can say that it’s a focus that only arrived to us a few months ago. Sure, in the past we have seen IT solution offering agility to the business, but that was just a coincidence, not a goal. New technologies like Business Process Modeling and, especially, Service-Oriented Architecture, not give us the opportunity to model an IT environment where the business can truly adapt change. Hence, the Business Agility emerges.

Like all IT strategies, Business Agility can be reached when looking at three elements. The first is technology (yes, this is a tech blog) which has to be chosen for the ability to support change with few changes in the technology itself. When technology isn’t able to rapidly adapt new business rules, new business processes or business users, agility within the business will never be achieved.

The second element we need to focus on is policy. Without a clear focus on delivering changes to the organization the business will not achieve agility. This is the part where Agile Software Development comes into play. But it’s not the only policy we need in order to make our business itself agile. We also need to incorporate Agile principles into the entire Enterprise Architecture stack. Not a simple and quick transition, but something that needs to ‘grow’ and ‘mature’ within the organization for a long period of time. The adaptation of Agile within the business processes (using methods like Lean Six Sigma) is one of the essential parts. As references show us, this is mostly a change of mind.

The third element is design. Even if an organization has the ‘state of mind’ to adopt agility within and the technology offers the possibilities to actually implement it in the organization, if the design isn’t focused on Agility, it will never happen. “Agility by Design”. Definitely something to think about and I will write about it soon.

Although we have traveled far since the old waterfall methods of software development, an agile approach to software barely stops at the way we organize our projects. True Business Agility isn’t gained if we don’t look at the outcome and possibilities a solution offers us when implemented.

One of the most intriguing sessions this tuesday of Oracle OpenWorld 2010 was the one about ‘The role of SOA in Enterprise Architecture’. Service Oriented Architecture is, in my point of view, simply a technology that offers us the possibility to combine business processes and system integration, but one thing it’s not: Enterprise Architecture.

It’s fairly simple: Service Oriented Architecture and Enterprise Architecture are two completely different subjects. Of course, SOA can take a role in developing an Enterprise Architecture. And probably a very important one. I’m glad that Harish Gaur, director of fusion middleware product management at Oracle, agrees with me.

During the session Haris Gaur helped the attendees gain insight in where SOA is able to be mapped onto various elements of Enterprise Architecture. A very interesting model is produced by Gaur and his team showing the SOA on EA Mapping.

Combining Business Process Orchestration, business services, data services and infrastructure against the 4 basic elements of Enterprise Architecture: Business, Information, Application and Infrastructure Architectures.

This cannot be a discussion: Service Oriented Architecture and Enterprise Architecture are not the same thing. But they do work together like a charm.

Today I was proud to be a part of the Oracle Enterprise Architecture Executive Summit 2010. Held during the Oracle OpenWorld conference it was a large and interesting group of people talking about the ‘next big thing’ in IT after the invention of the keyboard.

During the opening it was stated that, and I’m glad, that Oracle now has more focus on Enterprise Architecture because of the possibilities it creates for their customers. Of course, EA is a topic we can debate upon, but I must agree that Oracle has a big point here. It just might be the best way to make shure large implementations of (Oracle) software will pay off.

It’s good to see the Oracle interpretation of Enterprise Architecture (Oracle has it’s own process, framework and repository) is based upon the standards that are here today and have proven themselves. They didn’t invent it themselves.

During the exceptionally great session by Dr. Jeanne W. Ross I got a bit enlightened. EA isn’t done as much as I thought by grey people who love to document. It is, a I believe myself, all about strategy and agility of organizations, with the help of Information Technology.

One of the great conclusions of one of the break out panel sessions was that Enterprise Architecture is a collaborative process between Business and IT.

What have I been saying all this time?

(Will write more about the sessions at the Summit in the coming days.)

Yesterday, during the keynote session at Oracle OpenWorld 2010, Larry Ellison released the Oracle ExaLogic machine into the wild. After talking a lot about ‘The Cloud’ Larry announced that the machine is the ‘Elastic Cloud’ that you can put inside your own firewall. Sounds great, but is it really?

No. It actually is a brilliant combination of hard- and software, smartly combined with each other. Virtualization is something different than cloud computing. But Larry already knew that. It probably is the best machine to run on when you have loads and loads of Oracle products within your organization. But it’s not the cloud.

After the announcements of the past two years of the ExaData and ExaData 2, ExaLogic seems like the logical step into the middle tier hardware field. The combination is pretty impressive and it really will simplify rolling out and administer large clusters of Oracle Applications and Middleware Systems.

But it also means that you still have hardware running and you still have to buy some new before you can scale up. But you can scale up easily. Not the cloud. But it is elastic.

I’m really looking forward to learn more about this new combination of Sun Hardware with Oracle’s virtualization and Coherence software. Will it perform that good? And is it that easy to deploy?

What do you recon?

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.)

In most Enterprise Architecture frameworks the Business Architecture drives the Information Architecture.

But is this completely accurate? Didn’t we gain some new insights over the past few years. Information, and especially technology (or IT) Architecture can drive the Business Architecture, creating new and previously unimagined possibilities for organizations.

Modern IT isn’t anymore about offering the structure businesses can build upon, but more and more about offering insights in the way new technologies can create opportunities and thrive business. We talked about this principle before, it’s the ‘new CTO’ versus the ‘old CIO’. Both approaches are necessary in the modern organization. IT is helpful, but it also can actually push business.

This is exactly why IT and Business Alignment is a necessary, but outdated thought. It is time we start thinking with one, common goal in mind: the values set in the Business Architecture, the why, what, who and how of the organization.

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.

I know, tough one. When we take a look at Enterprise Architecture we tend to think of it as a fast and enormous endeavour. An extensive part of IT that only belongs in large organisations and within the service management organisation, not the project. At least, this is what I used to think about it.

When we take a look at Agile projects, architecture is a largely misunderstood element. This is, because we tend to think off it as the infrastructure our systems are build upon, but EA is so much more than that. We need three things: the technical architecture (the architecture part we used to look at, the infrastructure etcetera), the business architecture (derived from the business processes and the demands and wishes / requirements the architecture needs to be build upon) and the information architecture (the functionality and data within the architecture).

This doesn’t need to be an extensive document that takes months to complete. No, it’s a starting point, a continuous element within our project. Business architecture, for instance, is the definition of the business processes that are within the scope of our project, a description of the organisation and the derived actors within our project, the information architecture is the data, the distribution of data and the functionality. E.G. our user stories fit in perfectly.

In any project, even greatly steered Agile projects, there’s a beginning. A point where we need to define what we need to be doing in our project. Some call it iteration zero, some just start blank and put it into the first iteration, but we need to define the Enterprise Architecture (or better said, the project architecture) somewhere, in the beginning of the project.

Do you have an example of this? Where EA helped the project’s insights instead of putting unnecessary weight on the project.

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.