A value-up approach requires an explicit architecture, but it may emerge from the implementation. This creates an apparent contradiction. On one hand, you must consider all the QoS and deployment constraints in the context of the scenarios. On the other hand, value-up considers running tested code to be the best measure of system progress, and the act of developing is the act of designing, albeit at a very detailed level. It is exactly the act of development, in small fixed-scope iterations, that enables design to emerge from the implementation.
Baseline Architecture
A baseline architecture is a executable skeletal application designed expressly to mitigate technical risk and provide a solid, stable basis for project iterations. Some agile developers refer to this as “iteration zero” when platform infrastructure components are installed and a “thin vertical slice” of the system is built, exercising a very simple scenario from end to end (for example, from the user interface to the database). The goal here is to flush out and validate the project’s architecturally significant mechanisms unambiguously. Removing ambiguity mandates that the baseline architecture be executable.As an example, consider a popular application stylea web application using a relational database. A number of fundamental questions need to be answered early to determine the best fit based on good citizenship and all the perspectives of the advocacy groups , Should this application be bought or built? Should the application be a smart client or a web application? If it is a web application, what processing should be done on the client using technologies such as Asynchronous Java Script and XML (AJAX), and what processing should be done on the server? As for persistence (assuming a relational database), what are the organizational standards for the choice of a relational database? Should a new database instance be created, or should tables be added to an existing database instance? What is the source of reference data for this application? How does this application integrate with other applications in the enterprise? How many business transactions per day must this system be able to execute to support the project’s economic justification? Will this application be deployed, operated, and maintained in a corporate datacenter? If so, what are the technical constraints of the datacenter? As these fundamental kinds of decisions are made early in the project lifecycle, they result in constraints that guide and stabilize the project under development.There is a delicate balance to strike. As you work through these technical issues, try to defer decisions to the “last responsible moment.” The last responsible moment, however, will vary depending on project complexity. Often, you will let detailed design issues, such as interfaces and method factoring, evolve from implementation. In more complex projects with many dependencies, you may need to pin down interfaces and mitigate architecturally significant risks early to avoid later rework. Then, within the agreed policy, build an executable baseline that implements these high-level design decisions so that they can become architectural constraints on the project.Defining this baseline early benefits developers by providing stable platform infrastructure components and protocols for application development. Defining these constraints early also enables predictability and planning for other stakeholders. For example, Release/Operations can plan for the deployment and management of the application in production and can ensure datacenter readiness. Product management in the line-of-business can create marketing plans designed to attract levels of usage at transaction rates the system can support. Business analysts can design business process monitoring reports to analyze the application’s return on investment, which will feed planning for the next version.
Enterprise architects can design and implement reusable services across the enterprise, migrating toward an enterprise-level SOA. Defining these constraints early enables a stable, predictable basis for multiple stakeholders.
Validate Architectural Decisions
This process is not just top-down. You need to validate these constraints bottom-up by building an executable skeletal architecture. VSTS enables you to model your “asis” datacenter using the Logical Datacenter Designer and your “to-be” application using the System and Application Designers and then to run a validation report to identify conflicts between the two. Then your System and Application models can be used to generate skeletal code that can become part of your executable baseline.Doing so provides many benefits. The running code is unambiguousshould areas of design seem unclear, the source code can be consulted. The running code can be performance tested to validate initial transaction rates of the system. System settings can be verified against datacenter policies to identify potential conflicts. Also, building an executable system forces lower-level design decisions to become explicit, further refining the baseline.
Refining the Baseline
As you build out the skeletal architecture to run end-to-end, you are forced to consider lower-level design decisions. How will you structure your application logic? What is your data access approach? Will you deploy the business logic on the same server as the web server, or will you deploy them on separate application servers? What authentication and authorization mechanisms will you use? What protocols will you use between servers?Don’t try to address all the concerns yet. Choose the areas of highest technical risk to validate and let the other decisions emerge through implementation. Think about building the simplest skeletal application that will meet your constraints, mitigate technical risks, and still provide a sound, stable basis for development iterations.
knowledge and experience of others who may have also solved similar problems before and captured the learning in patterns.Patterns also give you a language with which you can concisely describe solutions, mitigate risk by reusing known good designs, and enable future maintenance and reuse of your work.
| .NET Framework-Specific PatternsFor patterns specific to the .NET framework, see msdn.microsoft.com/ practices. |
Reference Architectures
In many cases, you can use a reference architecture as a baseline. For example, Microsoft has created a reference application called Applied Integration Baseline (AIB), which uses a pattern-based approach to build an executable baseline , This application ships with more than twelve Visual Studio projects and is based on ASP.NET, BizTalk Server, SQL Server, Host Integration Server, and VSTS.
The Application Integration Baseline provides an interactive “Narrator” to visualize the baseline architecture. The visual models include VSTS Application Designer and Logical Datacenter Designer models as well as a pattern-based description of the system. Here the narrator is illuminating a scenario one step at a time by rendering each step on the Application Designer diagram.
Entries (RSS)