This project is read-only.

Chapter 15 - Enterprise Architect’s Perspective

The enterprise architect is responsible for ensuring consistency between products employed in or built by an enterprise. Their goal is to reduce total lifecycle costs (including operating costs, technology licensing costs, etc.) and to maximize the ROI of any common infrastructure. The enterprise architect often has veto powers over individual products that fail to comply with enterprise architecture principles. This sometime makes them part of the acceptance decision– when the product is built by an external supplier – and sometimes part of the readiness decision – when the product is being built in-house by an IT department.

As an enterprise architect, your job is to ensure the all the products used by the enterprise work well together and provide acceptable performance at an acceptable cost. Depending on the nature of your organization you may be called upon to provide data for either the readiness decision or the acceptance decision. In some organizations you might even be asked to be involved in making the acceptance decision. The role you play will depend on where in the organization you report relative to the supplier organization. In out-sourced development situations you are more likely to be involved in acceptance testing and the acceptance decision; for in-house software development and product companies you may be more involved in readiness assessment. Who you interact with will also depend on the nature of the organization. If there is a solution architect for each product, much of your interaction with the supplier team will be with the solution architect. In other cases you might be interacting primarily with a development lead or a project manager or even the product owner.

Understanding the Solution

While it is primarily the supplier team’s responsibility to work with the product owner to understand the desired product, you may need to be involved in these discussion if the supplier team doesn’t have a solution architect. Otherwise, you would likely work with the solution architect to undersand how the requirements of the specific product relate to the rest of the enterprise architecture. You would determine (along with Solution Architect) what forms of integration are required and how that integration should be implemented from a technical point of view. You would also collaborate to understand how the new product impacts any common infrastructure such as network, application and database servers, etc.. If the product has any impact on the long-term vision of the enterprise architecture, either by changing the vision or by implementing any key components, that information needs to be communicated to all parties concerned as the latter may become part of the readiness and/or acceptance criteria.

Ensuring Readiness

In some organizations you will be asked to provide readiness assessment information to the readiness decision maker. You will need to engage the solution architect or development leads to ensure they understand what standards or guidelines are applicable to the product and what reusable components should be used. You may also be involved in defining extensions to the corporate data models to support the new product. It is crucial that you communicate any expectations of how the supplier team would engage the enterprise architects during the readiness assessment and/or acceptance testing (whichever is applicable.)

Assessing Readiness or Acceptability

The nature of your organization will influence whether you are formally involved in readiness assessment or acceptance testing but the nature of the activities you do will probably be the same either way. Unfortunately, the later you are involved the bigger an impact a non-compliance discovery will have on the overall delivery schedule. Therefore it is preferable to engage the supplier teams earlier, before even readiness assessment, to ensure that the readiness assessment or acceptance testing/reviews are just a formal signoff of information that was previously discovered rather than an unpleasant surprise for everyone involved.
Some of the activities you might want to start doing even while development is in progress include design and architecture reviews that focus on standards compliance para-functional attributes such as security, capacity, scalability, and infrastructure impact. In some cases you may even be called upon to arrange for testing of para-functional characteristics of the system such as penetration testing.
If you find yourself on an acceptance decision committee, you will need to be prepared to gather and review the results of the para-functional reviews and testing and cast your vote on the acceptability of the product from a technical perspective. Let the product owner vote based on the functionality provided and the operations manager on their satisfaction with the operational requirements.

Last edited Nov 5, 2009 at 11:45 PM by rburte, version 1


No comments yet.