Architecture

The software architecture of any system is based on the requirements that have been negotiated between the various stakeholders. Depending on whether the requirements are for a specific application or software system, the stakeholders usually comprise of at least one or more of the following groups:

• Clients or users

• Support organization

• Quality Assurance organization

• Sales/Marketing organization

• Management organization

• Development organization 

Clients or users are obviously why a product is built, so their input is essential. But in many cases clients do not really know what they want. One big mistake producers of products make is to suggest to the client the features of an application. Clients will always want what every feature that is suggested even though they may not really need the specified features. A better approach is for the clients to describe their desired business application and based on the business needs define the features that are required.

The Quality Assurance and Support organizations are stakeholders since they are directly involved in the delivery and maintenance of the application. Their requirements will affect the quality of testing that can be done in the amount of time allotted and the turn-around time of problems that comes in from the field once the application is released.

Sales and Marketing organizations are always stakeholders since they need to generate the necessary collateral to sell the application (product) to various clients. They normally are on the front line with the clients and know what will be successful in the market.

Management is always a stakeholder since they are responsible for funding the development, testing, and maintenance of the application. And the Development organization is responsible for building the product, and therefore, may want to influence the requirements for various reasons like maintainability, performance, expandability, etc.

Once the requirements are formally specified, the architecture can be defined. In reality, even though the requirements are formally specified, they will change. This goes back to the statement above regarding clients don’t always know what they want. As described later, this is where the technologies using the iterative method benefit not only the client but the end product.

There is no one definition of software or application architecture, since it has evolved over the years based on different terminology. Application architecture involves defining the interaction between application packages, databases, and middleware systems in terms of functional coverage. IEEE defines architecture as: “The architecture of a software system (at a given point in time) is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.”  In other words, Architecture can be defined as defining the structures which comprise software components of the system or application, the externally visible properties including constraints of these components, and the relationships between them. In addition, the components and their relationships satisfy the defined requirements (that came from the stakeholders). Architecture can be categorized based on type, for example, Business architecture, Technical architecture, Solution architecture, and Enterprise architecture. The architecture paradigm chosen will depend on the problem that is to be solved.

As one can imagine, there were many software architectures that were good and many that were bad. When building any product, it’s always desirable to use a technique or solution that has worked in the past. As various architectures proved successful, certain architectural patterns were documented and reused, thus, pattern technology started to gain prominence in architectural patterns and design patterns. A pattern is defined as "an idea that has been useful in one practical context and will probably be useful in others”.  A documented pattern should indicate when it is applicable. For example, consider the client-server architecture. This architecture distinguishes client systems from server systems, which communicate over a computer network. This assumes that the client side software performs a number of functions and the server side software performs a number of functions. This was a very popular architecture in the 1980s and 1990s.  Usually, the number of clients was in the range of one to fifty, which was manageable for maintenance and problem resolution issues. However, this is not a good architecture for an application that requires thousands of endpoints that need to access the same resources like a database or internal state structures, for example, a transaction processing system. Here the ideal architecture is a three tier architecture – a thin client (no software), business logic server, and the database server, where all three can be on different platforms. In this case, the client requires no software updates or maintenance. All software updates and maintenance are performed at the business logic server and database server.

One of the latest architectures is SOA (Service Oriented Architecture). There are many definitions of SOA. One definition is that it’s an application architecture made up of components or services with well defined interfaces that interoperate in a loosely coupled manner. Some say SOA is more of a culture change to developing applications. SOA is usually associated with Web services, but it is more that just web services. SOA basically evolved from the CORBA broker and Enterprise Application Integration (EAI) technologies. SOA architecture is based on developing services, which are independent software structures that provide certain data. Applications are built buy calling these services. And of course, there are rules that must be adhered to when building a service so that a caller can discover the services and also understand the data being received.

Think of the Object oriented paradigm, where objects where built that performed a particular function. The application consisted of calling these objects to acquire the information then provided and presented the information to the user. SOA is very similar, but at a higher level. Think of services, like objects, representing a business service. The business service may consist of many other services, but in the end it’s a business function that is performed. So, it’s at a higher level that objects, but the same concept.

SOA can be industry specific. For example, the financial industry builds its services to certain specifications and the Manufacturing industry builds its services to another specification. As long as the application is contained within the specified industry, the rules remain the same. This doesn’t mean access to other services is not possible. It’s just a little more complicated.

read more