Architecting a solution

We Software engineers are practitioner of software engineering which states that we apply principles of engineering to design, development, maintenance, testing and evaluation of a software and systems involved in SDLC process. Instrumentation is emphasized mostly with various patterns and practices we come across while we are involved in SDLC process.

First of all it is difficult to define precisely the meaning of an architecture but I would like to take some approaches which might define architecture of a solution effectively.

First Approach:
First approach we deal while defining the architecture of a solution is so called pragmatic approach. Pragmatic architecture as the name suggest is about adopting the approach that works best for you and focuses on essential concrete tasks and priorities the work according to the value it brings to the project. A pragmatic architect is open-minded and follows activities that leverage the solution offered in many ways in following context:

P: Promote collaborative work that involves all team members
R: Reduce risks and uncertainties
A: Adhere to minimalism and simplicity principles
G: Gather key elements to outline the architecture during your initial timed-boxed iteration
M: Modify the design throughout the development lifecycle to adapt to emergent needs
A: Address both functional and non-functional requirements
T: Try out theoretical concepts and leverage past empirical experience
I: Invest in known requirement instead of hypothetical future needs
C: Concentrate on tasks that support the development team

Second Approach:
The second ideal approach is with defining the four metaphors of architecture which mostly relates to Data Collection and Analysis. These four metaphors are:

Architecture as Blueprint which defines the working implementation which involves in implementing or programming the system according to specifications.
Architecture as Literature which defines the solution or the collection of solutions made in the past which make us aware of the kind of system we have when we deal with heterogeneous environments.
Architecture as Language which defines the common understand about the structure of the system and let us know where we are going. This information serves as the communication between different stakeholders about high-level structures and solutions.
Architecture as Decision which defines the basis for rational decision-making concerning resources and strategies. This influence on needed resources when building the system, their special skills and the amount of money that must be spent on third party licenses.

Third Approach:
The third and systematic approach is defining the tier architecture with Business Logic Layer, Data Layer and Presentation Layer.

Business Logic Layer encodes the real world business rules that determines how the data can be created, displayed, stored and changed. This layer typically include Business logic components that is concerned with the retrieval, processing, transformation and management of application data, application of business rules and policies and ensuring data consistency and validity.

It generally comprises of Business Workflow Components which defines and coordinate long running, multi step processes implemented using Business Process management tools and Business Entity Components which generally represent business objects, encapsulate the business logic and data necessary to represent real world elements.
Data Layer consists of Data Access Components which abstract the logic required to access the underlying data stores and Service Agents which implement data access components that isolate the varying requirements for calling services from application like Caching, Offline support, etc.

Presentation Layer contains the components that implement and display the user interface and manage user interaction. This layer comprises of User Interface Components which are the visual elements to display information to user andPresentation Logic Components which defines the logical behaviour and structure of the application in a way that it is independent of any specific user interface implementation.

Fourth Approach:
We extend our layered architecture in terms of defining the Service Layer also which defines and implement the service interface and data contracts in accordance to provide translator components that translate data formats between business layer entities and data contracts without exposing details of the internal processes or business entities used within the application

To Summarize…

An architecture extends with various entities when we define a proposed solution for a new system or enhancing features and performance orientation of an existing system. Usage of various design patterns, ORM tools, Web Service and Shared Library implementation, Domain model creation with DDD approach, etc., always are the core components while we define the architecture.

We need to follow some pre-defined approaches when we are proposing an architecture for a system and ensure we follow these approaches to bring consistency during SDLC phase of a Project life cycle.

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.