Engineering Ideas
Published in

Engineering Ideas

The practices of information systems architecture

System analysis, risk analysis, requirements management, systems management, system synthesis, enterprise architecture, and change management

  • Not to forget something important when doing the architecture of a specific information system.
  • Evaluate the competence of candidates for information systems architect positions on a project.
  • Guide the development of people who play the role of a systems architect or want to start playing this role.

Outline of the practices

If the practice doesn’t properly belong to systems architecture, the discipline to which it belongs is given in parens (more explanations in the discussion below):

  • Model the data
  • Analyse the system
  • Discover, analyse, and manage requirements and the qualities of interest (requirements engineering)
  • Find and document risks
  • Set priorities and make plans (project/product/systems management)
  • Define and document internal system requirements
  • Develop and document the engineering methodology (enterprise architecture)
  • Manage internal requirements
  • Synthesise (design, develop, create) the system
  • Negotiate new external requirements with the system’s stakeholders (product/systems management)
  • Evaluate communication and collaboration risks (enterprise architecture)
  • Manage and plan architectural changes and their lifecycle
  • Evaluate the alternatives and estimate the risks of making the change

Discussion

In data modelling, architects use semantics, ontology, and the theory of information.

  • Estimate how well the system (already existing or envisioned), or a particular system’s function fare according to the system qualities that the stakeholders of the system are concerned about. Discovering (gathering, eliciting), analysing, and managing requirements and the qualities of interest (areas of concern) are the practices of requirements engineering (product management, product ownership) and not of systems architecture, but nevertheless, architects often do this, especially if there is no product owner in the org chart of the project.
  • Identify conflicts of requirements (qualities, mutual needs) among the parts of the envisioned system. Architects then resolve these conflicts during system synthesis, described below. A related idea by Tyler Neely: “If it’s hard to model or check specific invariants of a system, it could be a symptom that the architecture is unsound.”
  • Identify the pain points (hotspots, weak links), i. e., the places with the highest ROI of intervention to guide team priorities and future changes to the architecture.
  • “Trading” these requirements against each other for achieving optimal team velocity and minimising the cumulative engineering effort expended on the project over its entire lifetime. The development velocity doesn’t always need to be maximal if achieving this velocity itself will take more time than the entire project. Steve Tockey noted that “requirements have a half-life”. Priorities of internal system qualities also depend on the project’s strategy and future projects: for example, Will Larson recommends prioritising flexibility at the time of system growth because it saves a lot of time during system migrations and rewrites.
  • Tracking internal system qualities, such as code metrics.
  • Creating detailed plans for architectural changes to an existing system, including engineering the systems that support the transition (i. e., scaffolding), rollout plans and rollback plans in case of unexpected problems in production.
  • Documenting architectural changes, for example, with a record of alphas of project decisions.
  • Prioritisation and planning of architectural changes so that they don’t conflict with each other. Typically, the latter means just making sure that only one architectural change is in the works and rollout at a time. When there are multiple proposed changes that are inherently in conflict (implementing one will block off another and vice versa), only one change should be chosen for implementation.
  • Controlling that architectural documentation is updated when the change is complete and making sure that the systems that supported the transition are shut down.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store