- Designing Requirements
- What Is Design?
- Making IT Application Development More of an Engineering Discipline
- Taking IT Architecture into Account
- Concluding Remarks
This chapter is from the book
This chapter is from the book
This chapter is from the book
Taking IT Architecture into Account
At the beginning of this chapter I wrote that I have three objectives; so what about the third of these—support for IT architecture?
Unfortunately I have to explain some terminology here. I have used the words IT architecture as a catchall term for different kinds of architecture in the IT development space such as enterprise architecture, information architecture, and technical architecture. What I mean by taking IT architecture into account is having a concern for the whole of the enterprise’s IT resource rather than the single application. It is about looking for synergy, looking for data consistency across the organization, and creating an IT application portfolio that can be easily extended to support new functionality. It is about taking care of the integration across applications as well as the applications themselves.
Note that if IT application development becomes an engineering discipline, it would not, per se, be more likely that the applications will support the IT architecture. The same is true in civil engineering—just because a civil engineer has helped to design a building it is no more likely that the building will be in keeping with its environment.
There are several areas of design where architectural concerns are particularly important. One is the technology design. For most projects, there are a huge number of technology products you could use, so you have to select which technology to work with. You want to use technology in which your organization has expertise, and technology that is easy to integrate with your existing applications. The technical design must also help you decide how to structure the application and how to integrate with the organization’s systems management and security services. There are opportunities for reusing ideas, technology, and sometimes programmed code across many applications.
Another area is database design. The issue here is consistency of data across the organization, for instance, by having one copy of data for each customer or, if you have multiple copies, ensuring that they have the same information. The new application should be built to use data that already exists, or at least it should work with other applications to keep the data consistent.
However, the linchpin for ensuring that wider concerns are taken into account is deciding, early in the design, what existing applications and services to keep and what applications and services to replace, and identifying and implementing services that can be reused by other applications. This I call integration design, and I put it high up in the design hierarchy because the decisions just cited are central to deciding the scope of the development.