After several years of developing and using architectures we developed our B|D|A|T|S™ architecture methodology. "B|D|A|T|S” symbolizes the business, data, application, technical, and security views of an architecture. We expanded the core methodology to cover and federate four levels of architecture: enterprise, integration, solutions, infrastructure. Enterprise architecture looks across the entire organization as well as the eco-system of suppliers and customers. Integration architecture looks at a family of systems and end-to-end processes whiles solutions architecture address a single system. Infrastructure architecture deals the shared data centers and core services. This level is more applicable if you’re building the "cloud" instead of using it.
One the biggest problems we encounter, is that everyone has a different take on what architecture means to them. One person’s enterprise architecture can be another person’s solution architecture. Applying B|D|A|T|S™ views across the four levels really helps us overcome the ambiguous meaning of architecture and define its purpose and scope (“fit for purpose”). For example, the business view of enterprise architecture is very different from the business view of infrastructure architecture. The enterprise layer would look at the business model and capabilities while the infrastructure layer would focus on service catalogs and levels The other important aspect of the methodology is the ability to federate or link across the layers. This provides line of site from the business model to the individual applications and projects. It allows different architects to maintain the right level of abstract to suit their objectives - but still have the ability, when needed, to drill down to more detail or drill up for a bigger picture.
Federation is an important concept since most enterprise architectures are simply too large and complex to be described within a single integrated architecture (and by a single architectural team). A single architecture would be either too abstract and wouldn't be useful (30,000 feet and climbing anti-pattern), or would need to compile massive amounts of data that would be impractical (boiling the ocean anti-pattern). The federation approach allows for distributing, linking, and discovering architectural information across disparate teams.


