Jan Popkin | Enterprise architecture: a journey, not a destination

What developments are we likely to see with enterprise architecture this year? Some experts talk about the need for more data management, business processes and security.Enterprise architecture continues to mature. There is an understanding of what it is, and people are saying, 'Now that we are doing enterprise architecture, what benefits or actions do we want to result from that?' It's less, 'Should we or shouldn't we do the program?' [and more] 'We're doing the program now; let's tune it to our particular needs.'Enterprise architecture is a mechanism to provide results ' whether it's agility, alignment, collaboration ' and so'it is an enabler in itself. I see [users] looking for results, tuning programs. The other part of the enterprise architecture discussion is moving further out from an IT chief architect discussion to involving extended-team collaboration with other groups. And that opens up the questions of data management, business process and security.For instance, 'We have data we want to share ' what are the rules for sharing it?' 'We provide this process or business service ' how can we share it?'And security is an ongoing discussion. In the past, there has been discussion of laying in a security view. I think that's always been balanced with having security intrinsic across everything you're doing and having it especially called out.We're hearing a lot about service-oriented architecture and business process management. How can agencies apply these disciplines and associated technologies in an EA framework?When we talk about an EA framework, I'd like to map that into an EA program. An EA program is an ongoing mechanism to understand what your goals are and what an agency's service goals are and align that with IT services and business processes. So the enterprise architecture program or framework provides a context to understand the implementation of such a thing as SOA or business process management.But when we talk about SOA, there are multiple definitions of it. When I talk about SOA in this context, I'm talking about it as an architectural principle, which means supporting the agility of moving things around over time and [supporting] data sharing. I think in the federal space that is what people are talking about, which is having that agility and data sharing.It's not discussing SOA technology, it's talking about the architecture around it. Having said that, you can see the alignment of an EA program ' which involves understanding and defining services, an agency's goals and what it needs to achieve ' and then having the SOA architectural principle below supporting that in a high-level implementation.As you do the services, you have to involve the business processes around it. When you're talking about the SOA architectural principle, there are people and things around that and the processes which are very important to enable those SOA architectures.Tying that all together, the EA program is a higher-level view of what's going on, how that's aligned to where you are and where you are going.How have government agencies fared in implementing their architectures? The Office of Management and Budget launched the federal enterprise architecture (FEA) in 2002 to simplify processes across agencies. Has it helped?Enterprise architecture is a journey, not an endpoint. Enterprise architectures are programs. They are not static. They evolve. So discussing how agencies and the federal process [are] working, I'd like to step back and say it started with the Clinger-Cohen Act, evolved through the FEA framework, through OMB continuing to understand it and tune it, to now where we're dealing with the FEA reference models. Having said that, enterprise architecture shows change, evolution, understanding and approval.' So I like to look at EA as a series of journeys and a process. When I see that, I know it is healthy.What more needs to be done at this stage of the journey? Enterprise architecture is in the eye of the beholder. Each agency has its own focus and buries their EA program or their viewpoint about enterprise architecture within the services or mission that they provide.So you have to look at enterprise architecture adoption within the environment of each agency or group of agencies working together that are applying it. Some use it for IT consolidation. Others use it as a serviceoriented architecture or as a way to provide visualization at a higher level. Some look at it for financial controls and allocations, looking at where we have spent the money or want to spend it. Some look at is as a regulatory docket, which is [what we are required to do, how well we are doing it and what the processes to support it are].So what needs to be done in the future? It depends on the group you're looking at and where they are going. Each agency defines what benefits they are looking for and what they're trying to achieve, which does change over time and change based on the communities they support and what they're being asked to do.How are EA tools evolving? Will we see more integration between EA and modeling toolsets?There are a number of different trends going on in the enterprise architecture program or process business. One is the extended team, which is continuing to involve additional people around the architectural process. I'd like to think of it as the high-level executive group, operational group and technical group. And each group needs to be able to understand what is going on and contribute to it.Getting the geographical groups, people who are spread out, and making it easier for them to collaborate so they can contribute to different pieces is another trend. And I put this under the extended- team discussion of getting different types of groups together working in a comfort zone.I'm trying to stay out of any particular statement of technology here. I'm just giving the trend as opposed to any solution behind it.On the organization level, the executive and operational teams are brought into the extended team with improved visualization and analysis. Understanding what has changed over time has become more important. Everyone wants to see things in a visual way. For instance, IT wants to know how to communicate changes to the executive level, so they can say, 'Here's where we are, and here's where we want to go. Does this agree with our goals and missions?' If so, we'll start down this journey, and the enterprise architecture program on implementation will help us keep aligned to it.The other trend is that, as enterprise architecture is understood as a program, it continues to move its artifacts down across the implementation. It is important to provide traceability from a strategic statement or a compliance view all the way down to an implementation.We are starting to see traceability from a high-level strategy or business process or SOA service down actually to the implementation level. By this, I am not saying producing the code from the strategy; I'm saying providing the traceability from the strategy or service or process into the code.I see the connection with modeling allowing IT architects to take the different forms of modeling and say: 'Oh, that up there actually winds up producing that down there, and I can show you how we got there and why that exists and why that is an important thing.'The extended-team discussion and traceability are driving the tool vendors to provide stronger and stronger solutions in the area of EA tools.