Freigeben über

The PnP architecture meta-frame

  • Artikel

The Application Architecture Guide 2.0 by PnP introduces the concept of “an architecture frame”. It provides guidance on where to start and what key aspects to look for when designing the architecture of a system.

At the minimum a good architecture should:

  1. Determine the type of application to be built.
  2. The architecture styles to be used and
  3. how the cross cutting concerns will be handled

image

A typical approach to defining your architecture should be:

Understand the Business Goals and objectives – why are we building the application.

Understand the Organizational constraints: These might range from budget, hardware resources, human resources etc.

Decide on the Application Type: Understand the client requirements carefully to decide on what type of application will be the best fit for the end-user. The Application types might range from Rich client application to Mobile applications (see App Types in the figure above). The key here again is to think from a Business prospective and then from an organizational constraint prospective. 

Some of the guidelines to follow while deciding and recommending an application to be client might be (these are just the bare minimum a lot of other quality attributes need to be taken into account before recommending an application type):

  1. Rich Client: Suggest this when you want to leverage client resources and support disconnected scenarios. Microsoft Word is an example.
  2. RIA (Rich Internet Application): Support for advanced graphics and streaming media in a web deployment scenario.
  3. Web Application: Application UI over the web for various geographical clients. Minimum or no traces on the client machine.
  4. Service: You want to expose a loosely coupled interface to remove clients without a UI. You want to provide autonomous plug and play components that can be leveraged by a variety of clients. E.G.. . a Credit Card Verification service.
  5. Mobile: Support for mobile devices over the web / on the mobile device.

More on these in later posts …

Choose an Architectural Style: It is a set of principles. Each style defines a set of rules that specify:

  • the kind of components you can use to assemble the system.
  • the kinds of relationships used in their assembly
  • the constraints on the way they are assembled and
  • any assumptions about how you put them together.

Architectural style range from Client / Server, to Layered architecture to MVC, SOA depending on the kind of the application you are building.

Loads on these in later posts :)

Choose the right technology: Once you have decided on the Application Type and the architecture style to use, choosing the right technology can become simpler. Make sure the technology adheres to any organizational constraints and is stable to be delivered in a production environment.

Quality Attributes: These include – security, performance, maintainability etc.

Deciding on what quality attributes to apply for the system depends on the kind of application, priorities  of the quality attribute will differ from application to application or maybe component to component so it is necessary to evaluate the need to each quality attribute before recommending it. E.G.. if security is not a big concern for the organization then it can take a back seat and we can focus on other aspects such as performance etc. Having said that some of these attributes might be globally applicable to all or any kind of application.

This is a very interesting area since these attributes might not be visible functionally to the end-user but can still be essential for the system now or in the long run, making the business user understand the importance of Quality attributed is very essential.

Cross Cutting Concerns

These are the salt and pepper of the software, they represent key areas of your software design that might not be related to a specific layer. Some of these include:

  • Authentication
  • Authorization
  • Caching
  • Communication
  • Exception Management
  • Instrumentation and Logging

Comments