Freigeben über

Architectural design tenets and corollaries

  • Artikel

Now that the codename “Oslo” repository is public I can discuss its architecture and design.

When designing a new product or component I like to:

1. Understand the business landscape. For example, what is the market opportunity, what are the major competitors, where are the competitors likely to be by the time the product is released, how will the product fit into customer’s business processes. Creating new products is difficult and expensive so it is important to get this part right. Also an in-depth understanding of the business landscape can help enormously in day-to-day decisions. For example, can a feature wait until version 2?

2. Create design tenets. Design tenets are the bedrock on which good architecture is built. Any non-trivial design must make tradeoffs—design tenets help drive decisions by succinctly describing what is important. Without design tenets, scope creep and over-engineering can easily destroy a design.

I did an extensive multi-version business analysis for the “Oslo” repository which, of course, I cannot share with you but here are the “Oslo” repositories design tenets:

Integrate well with Oslo. Oslo should provide a seamless platform. The “Oslo” repository should integrate seamlessly with the rest of the Oslo platform.

Support a wide variety of tools. No toolset can fully anticipate customer needs. Support for ad hoc queries and updates, using familiar tools, will allow customers to circumvent the limitations in our tools. For example, it should be straightforward to build an Access based application over the “Oslo” repository or write a query that finds code vulnerable to a new security exploit.

The need to support traditional tools implies that the “Oslo” repository uses a straightforward relational representation of data as its primary API. Further to make queries easy to write, the metadata stored in the “Oslo” repository should form an integrated and consistent whole.

Scale well. Deployment and code analysis data (e.g. call graphs) can be very large. The “Oslo” repository needs to scale well to provide consistently good performance even when it contains a large enterprise’s metadata. In particular, good geo-scaling is likely to be important in “Oslo” repository scenarios.

Enterprises vary in their scaling strategies, the “Oslo” repository needs to support both scale-up and scale-out strategies. In particular, the “Oslo” repository should be designed to align with the SQL Server’s scale-out strategy since it will offer customers the most cost effective scale-out architecture for the near future. In practice, this means that “Oslo” repository data should be easily partitionable into related segments.

Support high availability. To be credible, the Oslo server will need to be highly available. As a critical component of the Oslo Server, the “Oslo” repository will also need to support high availability.

As well as being highly available itself, the “Oslo” repository should also support building fault resilient components that can survive “Oslo” repository failures. In particular, the “Oslo” repository should be designed to align with the SQL Server scale-out strategy and OCS (Occasionally Connected Systems) changes since they will offer customers the most cost effective high availability architecture for the near future. In practice, this means that “Oslo” repository data should be easily partitionable into related segments.

Be easily extensible. To quickly instantiate the “Oslo” repository with domain models for a wide variety of metadata and allow partners and customers to extend Microsoft tools or create new ones, the “Oslo” repository needs to be easily and cheaply extensible, supporting domain model extension and composition.

Ideally, the “Oslo” repository should make it easy to design and build domain models with, preferably, a wide variety of standard development tools or, less desirably, special purpose tools.

Support schema evolution. As technologies evolve, so will our domain models. The “Oslo” repository must support the easy and robust migration of applications to new domain model versions.

The “Oslo” repository should use good relational database design to ensure easy schema evolution. Because object-oriented meta-models are fragile, fixed object-oriented domain APIs should be avoided.

Comments