Application and solution architects' primary concern is to deliver new business capabilities via application development or business process integration projects. This is pretty familiar territory: the business wants to be able to provide X function by Y date, and the IT architect needs to work with the business and development to make sure that these capabilities can be delivered within the specified timeframe, and with adequate non-functional qualities (e.g. response time, availability, etc.).
Enterprise architects on the other hand are concerned with the long-term goals of all of the system. Usually these goals are focused on a couple of particular non-functional requirements like data integrity, modifiability, and reduced expenditures (e.g. consolidating redundant systems into a common system).
Note - for the rest of this blog, I'm going to write from the perspective of the application architect, since it's the role I'm familiar with.
It's always important on any IT project where you're acting in a leadership role (project manager, architect, lead developer), that you recognize all of your project's stakeholders and understand their authority to influence your project's scope and the specification of the to-be system that you're designing. Too often projects only recognize the business stakeholders as the entire set of project stakeholders. In reality their are many different stakeholders, often with conflicting priorities. Here are a few stakeholders common on most projects:
- The business area, who pays for the project and whose bottom line will be affected by the success or failure of the system
- The system development team, who will dedicate months or years of their lives to the development of the system and whose careers may be influenced by the success or failure of the system
- The government, of the country or countries where the system will be used, and may regulate some aspect of system behavior (e.g. limiting data collection and sharing to ensure users' privacy)
- The larger business unit, whose broader economic interests may be affected by the systems' compliance to larger architectural blueprints
This last stakeholder is usually represented by folks who call themselves "the enterprise architecture group" or often "the architecture review board"
The problem is that strategic architecture groups longer-term goals often upset the tactical project team, who are simply focused on meeting short-term business requirements. This really shouldn't even be the project team's issue. There should be agreement between the application's business owner and the strategic architecture group to recognize the long-term importance of aligning to common patterns and technologies, but often the business owner is trying to meet short-term financial commitments, and fuzzy talk of buzzword-laden phrases like "componentization" or "service-oriented architecture" often sound like esoteric matters of technical style and beauty, rather than as mechanisms that will positively impact the business in concrete and measurable ways. Often though, the business owner and archtictural standards group do not sync up, and the project architect gets caught in the middle between the stakeholders with conflicting goals.
This can get ugly, especially when the project team have to go through an architectural review with the architecture standards group. Non-compliance with a strategic technology or architectural style can lead to a game of chicken, where the architecture standards group threatens to disapprove of a system specification and the business owner squawks about the architectural standards group trying to derail his or her business for the benefit of technical benefits that won't be realized for several years, if at all.
This is why it's very important for the architectural standards group, and the business unit, to work closely together to focus on technologies and techniques that both agree will contribute to long-term business goals (e.g. improved ROI or flexibility), and then to communicate these business/technical goals as high-priorities to lower-level system/application/product owners, to ensure that the enterprise standards are seen as a first class priority.
Sometimes, a near-term business need will still be in conflict with a long-term architectural direction. In this case there needs to be well-defined process to do a trade-off analysis between the conflicting priorities and perhaps one person with the knowledge and authority to cut the gordian knot.
It's my understanding that the IBM Software Group architecture board has had a fair amount of success over the past couple of years moving IBM software products to common platforms (i.e. Eclipse and J2EE) and achieving significant degrees of reuse across the product line through a successful componentization effort. It would be really interesting to hear about the tensions between the IBM Software Group architectural review board and software group products from an IBM blogger on the board. Don Ferguson leads the board, and I believe Alan Brown, Simon Johnston and Grady Booch are members. Any takers?