Community Roundtable: Agility versus Architecture

I'll throw one thing out on the table that recently has come up, and that's the notion of capabilities within enterprise architecture. I think it's important to be able to discern, model, and otherwise communicate capabilities. But some folks get frustrated down the line saying, "Oh, enterprise architects, all they do is talk about capabilities." They're these kinds of boxes on a chart. It's like, here's a box and inside of that there is some real detail and stuff that is important.

I certainly see the value of mapping things out at the capabilities level, but it's interesting that sometimes folks down the line don't quite see that. They want to see the detail, but they get upset when they see just capability maps and that type of thing. But some people love capability maps and that's really how they see things. It's interesting, the dichotomy and the anger that can come up. Different people expect different things and they're not seeing those things.

What I recently experienced is all this buzz about the Agile methodologies. What happens, as Pat mentioned, a lot of people don't want to see the architecture on the enterprise level. They want to quickly jump to the details, and they miss a very big point, that if your architecture is not right, if you're not planning capabilities and key messages correctly, down the road, the whole building may just collapse.

Very often, in my practice, I see that "agile" is a substitute for the word "impulsive," and not a lot of attention is paid to how it will be on the top level. Many people think that it's not that important to plan and put the boxes in: "Let's just quickly put something together." Lately, you see that because there was not enough planning on how those boxes communicate with each other, you cannot really put anything more into it.

So you see a conflict between Agile and Architecture?

It's funny. I just read an editorial in a computer magazine about this topic. The editor was musing about a few recent failures of larger IT projects in Germany, where people really started with the big picture and were making elaborate plans, and were spending millions of euros over the course of several years, and nothing really ever came out of it. The solution that came out in the end was really not that impressive.

He then compared it to other projects—mostly run by the government, by the way—where they started small and agile and started building things as they went along, and weren't shy about re-engineering or re-architecting the solution over the course of the project. I think you should keep an eye on the overall architecture, but you shouldn't over-engineer it. I think you can combine Agile approaches with this as well. You just need to make sure that both levels are being addressed properly.

No matter whether it's Agile, or a long-term project, or an Enterprise Architecture, what I see a lot of is people using technology, or using solutions, based on who's in the room and what's the flavor of the day. Small projects have a tendency to do this because you want to get them done quickly. So if you have a person sitting around who knows Ruby on Rails and knows MySQL, or knows NoSQL, that's what the project gets delivered on.

The same thing can happen in Enterprise Architecture. Everyone has these grandiose plans — that we're going to use UCS Blades, we're going to maybe use an Oracle database, then we're going to use Glassfish for the middle tier. But then exceptions always creep up. Then people bitch and moan about their legacy architectures and their current infrastructure as being too unwieldy and supporting too many different technologies. I see most companies making the same mistake they made 20 years ago, which is frustrating.

So how do you get stakeholders to get past their comfort levels? I would think, especially now, with so much happening—cloud computing, service orientation, big data, the massive explosion in mobile computing—that in terms of moving any enterprise forward, the whole idea of comfort level would be out the window.

If you're going to have a presence, if you're going to be able to deal with the realities of the current business ecosystem, let alone what's happening in IT, you're going to have set your comfort levels aside and say, "Okay, how are we going to deal with these things?"

I deal a lot of with the stakeholders, and from what I see, the best approach is functional prototyping. If you allocate a certain amount of the resources to create a functional prototype—which is not in production, maybe running in your query system, maybe running in your development system—and show it to the stakeholders, they can see that this is something we can do. This is something we can move forward with. That is much easier than just showing them on a piece of paper. It obviously will take considerably less resources than putting it right into production.

That's what I see — functional prototyping, where they can see the data moving, where they can see how it works. Sometimes we can even show it to our real customers, so they can put a word in and tell us, "Oh, yes, I really like that feature. How about adding this one?" Then we can build on it and slowly move into production without disrupting the current state of affairs. That's how we deal with the legacy systems.

So more incremental changes instead of making big bang modification steps happen all at once.

Yes, I agree with the idea of the functional prototype, not a big bang, because big bang just never works. You've got to have a big bang approach, to begin with the end in my mind, but then approach it tactically. But, the other thing I was going to add was training. For example, let's say it's a new technology. When people aren't familiar with something, they're afraid of it. That's only natural.

The thing you've got to do, whether it's a technology, or an approach, or whatever — part of what we do as enterprise architects is we sell. We sell ourselves. We sell approaches. We sell technologies. But we also sometimes need to train people, to teach people why a particular thing—SOA, Big Data, whatever—is so important.

Let's spend a little bit of time educating the people that make the decisions. Show them what they need to know. So that, instead of kneejerk reaction, they can see—in the case of a functional prototype—they can actually see it working. They can understand it, rather than just making uneducated guesses about it.

We live in an era of APIs, and when you create the functional prototype, you can open right away a lot of the APIs and let your partners try it. This way you can see input from them. They can tell you, for example, that a service will not work for them because it will not feed right into what they already have.

To change it at the level of the prototype would be much easier than later trying to push them to integrate with your product. This way, the issue of training will be much easier later, along with the issue of integrating with their products, because they will have an opportunity to add their input right away when you are still in the development process.

That reminds me of two sayings that are pretty popular or common in the open source scene. One is, "You have to release early and release often." The other one is, "Don't worry, be crappy." Get the stuff out of the door and don't spend too much time on perfecting it. There is time, once you've actually released the version and you get going with it.