Architecture Styles

Abstract

Software architecture describes the structure of a system where it represents a collection of components that are responsible to accomplish a set of functions within the system. Software architecture focuses on organizing the software components that are required to support specific functionality within the software. In addition to the components grouping, the software architecture also focuses on explaining how the software components will interact with each other (MSDN, 2011).

Software application architecture is the process that defines the structure solution that can meet all the operational and the technical requirements, while optimizing the common quality attributes such as security, performance, and manageability. The purpose of the software architecture is to achieve the design required for common problems, and build the solid foundation for the software and application to run without any implications that can be raised from the platforms or the software components. Having a poor architecture can expose risks that can lead to unstable software and implementing the software that is unable to support the existing and the future of the business requirements, and also creates difficulty for such software to be deployed and managed within the production environment (MSDN, 2011).

MSDN (2011) explained that in design the software architecture, it’s imperative to adhere to the proven principles of the design that can maintain requirements, reduce cost, and promotes extendibility and usability to the software. The following are the key design principles that should be considered in creating software architecture:

  • The application should be divided into distinct features that can promotes a little overlap in functionality and as such; the minimum interaction points can be achieved that can promotes low coupling and high cohesion among the software components. However, separating functionality at wrong boundaries should be avoided, since such mistake in the design can result in complexity between features and produce high coupling.
  •  Each module or component within the software should be responsible for only a specific functionality or feature.
  • Object or component should not know any internal details of other objects or components.
  • Functionality shouldn’t be repeated in different components, and as such; the uniqueness of such functionality within a specific component is the key of the best practice in the design.
  • The goal of the software architecture is to eliminate the complexity of the software by separating the design into different areas of concerns (e.g. Business process, data access, user interface represent different areas of concern). In designing the components, each area of the design should focus on that specific area and the code of one area shouldn’t be mixed with other areas of concern.   
  • In designing the software architecture it is important that such design addresses future challenges and requirements and as such; such design should support flexibility.
  • It’s important to use the right tools that can help capture the key architectural decisions and requirements such as UML while the capability of iteration and adapting the easy design where it should be the main goal.

Software Architecture Style

The software architectural pattern or style represents an abstract framework of a set of principles that can be used for systems implementation where it promotes the reuse of the design and where solutions are provided to frequently recurring problems. Such styles are used to shape applications and understanding such styles provides several benefits. One of the most important benefits that the software architecture style provides is the common language and opportunities for technology agnostic to understand the problem and the solution for such problem, and it also facilitates a higher level of patterns and principles that can be involved in any conversation.

Seshadri (2007) argues that Service-Oriented Architecture (SOA) is an architecture style that can come into play when an organization implementing a front-end back-end architecture where the back-end consists of all the applications that are developed on J2EE, Microsoft .NET, or Mainframes while the front-end consists of all the business channels such as desktop, web –based and web services that can be exposed to any organization’s clients and partners. SOA provides the reuse of the existing assets and the high flexibility that enable a faster response to the future changes in any architecture.

For SOA to work in such case, the back-end must be broken into a set of services where each service performs a specific business task. Once such process is complete, such services can work together to form the business process. In such case, the SOA separates the business logic from the process logic where business logic is represented as services while the process logic is constructed to link these services together. The architecture process is starting by identifying the services; and then implementing such services to be independent and loosely coupled (I.e. the service can be compared to a method that takes parameters as an input and returns the processed output). To achieve the loosely coupled architecture, SOA mandates that a service can be invoked by any type of a client independently from any languages or platform implementation. To achieve that, Web services (SOAP) technology is used to expose the business logic to any client where services can be exposed by writing wrappers around them that can make the business logic available for different systems in any heterogeneous environment. A good example for such implementation is having a Microsoft .Net front-end application that can use the J2EE back-end that can be exposed as services that can provide support for a business task (Seshadri, 2007).

Changing in the businesses in most cases related to the process logic, rather than business logic, and with such architecture if any of the business tasks is missing, only the service containing the business logic will be required to be developed and tested for deployment (Seshadri, 2007).

 Strength and Weakness

The Services-oriented Architecture (SOA) promotes the incremental development from the foundation, and as such it reduces the cost of changes, the overall risk, and it serves as a starting point for any organization to build a flexible architecture (Seshadri, 2007).

Ghag (2007) explained that some of the pros and cons of the Services-Oriented Architecture are:

  • Through the service-oriented architecture the business process is well defined, and aligned with the actual business requirements from the software and applications aspects.
  • With service-oriented architecture, the services and processes within an organization are more adaptive to the changes in business requirements.
  • Service-oriented architecture promotes the re-use of the business logic in the form of services at the enterprise level.
  • Service-oriented architecture provides the integration within the enterprise via standards that describe the service, service registration, service invocation, and service implementation.
  • Implementing the service-oriented architecture create a stateless services issues where business logic mandates that the service should be stateful.
  • Services-oriented architecture raised some performance issues due to the technology stacks for implementation, and also the statelessness issue created by such architecture.
  • Service standard within the services-oriented architecture still based on the request-reply paradigm, and as such; it’s not useful for the loose coupling.
  • Some hidden coupling can be introduced within such architecture due to the sharing of persistent data.

Conclusion

MSDN (2011) explained that application architecture seeks to build a bridge between the technical requirements and the business requirements through a deep understanding of the use cases of such software and finding the best solution to implement these use cases within the software. To achieve such goal, the software architecture should be able to identify the requirements that might affect the structure of the application, reduce the business risk associated with building the technical solution, and build the design that can handle changes that will occur over time in the software technology, and the hardware without any tradeoffs that might effect the software security or performance. In designing any software architecture, the following rules should be considered:

  • The software architecture should expose the structure of the software and hide the details of the implementation of such software.
  • The software architecture should maintain all the scenarios and the use cases defined for such software, and also defined all the requirements defined by the stakeholders.
  • The software architecture should be able to handle both the software quality requirements, and also the functional requirements of the software.

MSDN (2011) argued that in designing the software architecture it is important that the following questions are answered:

  • What part of the architecture foundation that can represent a great risk if something went wrong?
  • What part of the architecture that most likely to change over time, and which part of the design that can be delayed without imposing any impact on the project.
  • What are the key assumptions in the architecture design, and how such assumptions will be tested?
  • What part of the architecture design that might re-factor?

Finally, Skonnard (2005) explained that service-Oriented Architecture (SOA) addresses the day-to-day activities of the enterprises than any other design paradigm. When we look at the architecture that can fit the business need we need to address the following concerns of any organization:

  • How such architecture will meet specific business needs?
  • What will be the cost to maintain and to manage such architecture?
  • Is the architecture will adapt the growth of the business over time?
  • How long it will be necessary for any organization to start over and rewrite?

The Service-oriented architecture takes the enterprise component technologies to the next level by stripping them to work as a service oriented (black-box) abstraction, where application can interact with such components by exchanging messages over specific communications protocols (Skonnard, 2005).

References

Ghag, G. (2007) SOA Pros and Cons [Online]. Available from: http://ganeshghag.blogspot.com/2007/01/soa-pros-and-cons.html (Accessed: 05 March 2011).

MSDN (2011) Key Principles of Software Architecture [Online]. Available from: http://msdn.microsoft.com/en-us/library/ee658124.aspx (Accessed: 05 March 2011).

Seshadri, S. (2007) SOA: Understanding the architecture [Online]. Available from: http://www.networkworld.com/news/2007/080707-soa-understanding-the.html (Accessed: 05 March 2011).

Skonnard, A. (2005) SOA: More Integration, Less Renovation [Online]. Available from: http://msdn.microsoft.com/en-us/magazine/cc163850.aspx (Accessed: 05 March 2011).

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: