SOLUTIONS ARCHITECTURE

The role of “Solutions Architect” requires the knowledge and skills that are both broad and deep.  To be effective the Solutions Architect must have experience on multiple Hardware and Software Environments and be comfortable with complex heterogeneous systems environments.  The Solutions Architect is often a highly seasoned senior technocrat who has led multiple projects through the software development process or systems development lifecycle (SDLC), and has usually performed in a variety of different roles in that life cycle. The person needs an ability to share and communicate ideas verbally, both orally and in writing, to executive staff, business sponsors, and technical resources in clear concise language that is the parlance of each group.

A practitioner of solution architecture, systems engineering and software engineering processes, the Solutions Architect is the person who organises the development effort of a systems solution.  The Solutions Architect is responsible for the development of the overall vision that underlies the projected solution and transforms that vision through execution into the solution.  The Solutions Architect becomes involved with a project at the time of inception and is involved in the Functional analysis (FA) of developing the initial requirements.  They then remain involved throughout the balance of the project.

The Solutions Architect is an expert in many categories.  They should have hands-on experience in multiple industries and across several disciplines.  They can master a variety of hardware platforms including mainframes, distributed platforms, desktops, and mobile devices.  Akin to that they should also possess skill and understanding of a variety of Operating Systems.  A broad and deep understanding of Databases is also required.

Solutions Architects decide which technologies to use.  They work very closely with developers to ensure proper implementation.  They are the link between the needs of the organisation and the developers.

PROJECT MANAGEMENT

There are a number of approaches to managing project activities including lean, iterative, incremental, and phased approaches.

Regardless of the methodology employed, careful consideration must be given to the overall project objectives, timeline, and cost, as well as the roles and responsibilities of all participants and stakeholders.

The traditional approach

A traditional phased approach identifies a sequence of steps to be completed. In the “traditional approach”, five developmental components of a project can be distinguished (four stages plus control):

Typical development phases of an engineering project

1. initiation
2. planning and design
3. execution and construction
4. monitoring and controlling systems
5. completion

Not all projects will have every stage, as projects can be terminated before they reach completion. Some projects do not follow a structured planning and/or monitoring process. And some projects will go through steps 2, 3 and 4 multiple times.

Many industries use variations of these project stages. For example, when working on a brick-and-mortar design and construction, projects will typically progress through stages like pre-planning, conceptual design, schematic design, design development, construction drawings (or contract documents), and construction administration. In software development, this approach is often known as the waterfall model, i.e., one series of tasks after another in linear sequence.  In software development many organizations have adapted the Rational Unified Process (RUP) to fit this methodology, although RUP does not require or explicitly recommend this practice. Waterfall development works well for small, well defined projects, but often fails in larger projects of undefined and ambiguous nature. The Cone of Uncertainty explains some of this as the planning made on the initial phase of the project suffers from a high degree of uncertainty. This becomes especially true as software development is often the realization of a new or novel product. In projects where requirements have not been finalized and can change, requirements management is used to develop an accurate and complete definition of the behavior of software that can serve as the basis for software development.  While the terms may differ from industry to industry, the actual stages typically follow common steps to problem solving —”defining the problem, weighing options, choosing a path, implementation and evaluation.”

PRINCE2

The PRINCE2 process model

PRINCE2 is a structured approach to project management, released in 1996 as a generic project management method.  It combined the original PROMPT methodology (which evolved into the PRINCE methodology) with IBM’s MITP (managing the implementation of the total project) methodology. PRINCE2 provides a method for managing projects within a clearly defined framework. PRINCE2 describes procedures to coordinate people and activities in a project, how to design and supervise the project, and what to do if the project has to be adjusted if it does not develop as planned.

In the method, each process is specified with its key inputs and outputs and with specific goals and activities to be carried out. This allows for automatic control of any deviations from the plan. Divided into manageable stages, the method enables an efficient control of resources. On the basis of close monitoring, the project can be carried out in a controlled and organized way.

PRINCE2 provides a common language for all participants in the project. The various management roles and responsibilities involved in a project are fully described and are adaptable to suit the complexity of the project and skills of the organization.