Architecture Landscape and Decisions

Architecture landscape

I want you to start thinking about architecture as the shape of the landscape. Start from a very high-level view where you have the entire enterprise broken down into problem spaces. Then, for each problem space, you have one or more systems fulfilling the need, just as islands sit in an ocean. Go to a whiteboard and draw your enterprise, organization, or department. Connect lands where systems integrate.

Lines connecting islands represent data flowing through domains, which often prescribes usage or implementation of individual applications. Business typically speaks the language of this data, its attributes, and operations, through which information transforms, slices, and rejoins.

Building out every enterprise happens similarly; understanding business and data, and putting solutions around these assets.

If you stay at this level of the thought process for a while, it becomes irrelevant to know how exactly each software system is implemented, how difficult it is to build such systems, and where their boundaries are. All that matters is that the entire landscape of solutions fulfills the end-to-end business needs.

Build vs. buy

Once you have mapped your organization’s business landscape, the next question is how to implement each identified system. Two possible choices are buying versus building.

If you are at a small enterprise, buying off-the-shelf software may be an attractive option. Where you need to be careful is the product’s ...