Software architectural design produces finished structures as deliverables. The software architecture process itself is nonlinear and requires multiple, parallel development paths and iterations. During the development process, dependencies on a vendor product, a technology, or the impact of new technology or client business practices in response to changing economic conditions may require changes to the architecture. Software architecture is a living process that is closely coupled with the full life-cycle of a project.

Software architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.
Source: IEEE Standard 1471:2000 - Recommended Practice for Architecture Descriptions of Software-Intensive Systems

IEEE Standard 1471:2000 provides a framework for describing an architecture. The architectural description is based on the terminology of IEEE Standard 1471, a recommended practice, that presents consensus elements of good practices in describing architectures. There are five core compliance elements that must be met by an architectural description:

• Identifying the stakeholders of the system and their architectural concerns
• Selecting and defining viewpoints to address those concerns
• Documenting views of the architecture satisfying those viewpoints
• Recording any known inconsistencies between views
• Providing rationale for architectural decisions made in the architectural description

IEEE 1471 concentrates on describing architectures through views, which are mapped to specific viewpoints:

• Viewpoints are the reusable parts of architectural descriptions
• Architectural descriptions require multiple views
• Views describe the system from the perspective of the system’s stakeholders
• The contents of views should be described by a Platform/System Independent viewpoint description

Architecture-Driven Software Construction

ASR Strategic Resources is active in promoting software architecture through the Association of Information Technology Professionals (AITP) and the Worldwide Institute of Software Architects (WWISA). Our enterprise architecture doctrine recognizes eight core architectural activities within two major software construction phases:

Architectural Phase

Pre-Design documents the needs of the client and defines the scope of the project. Key design points, requirements, and processes are examined within the context of the project. Available resources are assessed including financial and intellectual capital.

Domain Analysis documents the business and technology environment in detail. Project scope and client expectations are defined. Domain experts provide specialized knowledge for key issues such as technology choices, infrastructure details, and implementation approaches as well as client business workflows.

Schematic Design documents the structure of the system by combining graphical notations such as UML with linear (text) notation. Items such as the system's look and feel, workflows, transformations, data stores, and deployment characteristics are described in detail. Enough detail is provided for proof of concept and prototype builds.

Design Development documents the final design of the system in detail. Client requirements are mapped out and defined with sufficient detail to provide a benchmark against which client expectations can be validated regarding the design and implementation.

Project Documents consist of the artifacts required by the people that will actually build the system including budgets, resources, roles, construction sequences, tools, methods, and style guides.

Staffing and Contracting identifies who will play a role in building the solution internal staff, contractors, or outsource services. Bids are issued, selected, and awarded. Contract details, project costs, resources are assigned (both human and material), and the sequence of development activities are worked out in detail.

Building Phase

Construction is supervised by the architectural team, which in turn is managed by a chief architect who bears overall responsibility for maintaining design integrity and the design vision. Design reviews and change requests are evaluated, managed, approved, and documented by the architecture team.

Post Construction is supervised by the architecture team with regard to rollout. Migration, warranty, training, and maintenance issues are coordinated and overseen by the architectural team as well.

Architectures

ASR Strategic Resources is experienced with a number of standard software architecture models and frameworks including:

• Zachman Framework
• ISO/IEC 10746-3 RM-ODP (Reference Model of Open Distributed Processing)
• Kruchten 4+1 View Model (Unified Process)
• C4ISR Architecture Framework (Command, Control, Communication, Computers, Intelligence, Surveillance, and Reconnaissance)

Architectural Notation

ASR Strategic Resources has adopted the Unified Modeling Language (UML) for graphical notation. Because the Unified Process and UML have a number of shortcomings, we supplement them with additional notations and architectural frameworks. UML is supplemented by Object Constraint Language (OCL) and linear (textual) notations to provide detailed design information. Our architectural practices rely heavily on code generation technology to automate the development process. The use of linear notations and Architecture Definition Languages (ADL) provide a code generation mechanism. UML by itself, or even in conjunction with OCL, is not capable of providing the detail necessary to support automatic code generation.

Architectural Tools

ASR Strategic Resources uses a number of enterprise tools to support our architectural development process. Our internal tools are built around our Auldenfire Atelier framework and include Auldenfire Legion. External tools include Rational Rose Enterprise Edition and Computer Associates COOL:Gen.

Top