Clever Geek Handbook

What architectural perspectives do you consider as part of your overall software?

When someone uses the term XXX architecture, I tend to cringe. This often indicates that there is another architectural discipline or perspective that I probably am not considering. What architectural perspectives are you considering and do you have good resources for information on them?

I hope this helps others who are pursuing the profession of an architect.

  • Vitality
  • Performance management
  • Operational monitoring and control
  • Service orientation
  • TOGAF defines a number of qualities of service attributes

Sorry for the edit, but your answers were accurate and I think this question needs to be clarified.

0


source to share


3 answers


Architecture and architectural decisions are mainly concerned with the "non-functional" requirements of the system; the pace of the RoadWarrier, but each of the things he mentions are consequences of architectural decisions, more in their own right. (Proof: What leads to certain choices in any of these areas? There are always some non-functional requirements to be met.)

With that in mind, it's a two-part problem. First, you need to decide which NFRs are important. preferably by specifying them with some specificity, using a rigorous method, for example not just say "highly available", say "system must be available (MTTF / (MTTF + MTTR)) 99.99 percent, with the longest single break 4 minutes ...

Second, you need to think about what perspectives will help you develop to meet those demands and justify your decisions. Depending on the severity of your requirements, this can be anything from a flowchart of a board to formal modeling.



In a business area, say an IT system accessible via a web interface, you might, for example, want to:

  • reliability (MMTF)
  • availability (MTTF / (MTTF + MTTR))
  • (the system should be able to add 10 percent capacity within 72 hours at a cost of X)
  • capacity (the system must support 1 million active users)
  • throughput (the system must process 100 transactions per second with & sigma; = 2.5 tps)
  • response time (under test load, the user should receive a full page in ≤ 2 seconds)
  • security (metrics here are a topic for a separate article in itself)

You should also specify if you are specifying performance characteristics, etc., describing the workload, i.e. size of user data, rate of arrival of web requests, etc.

+1


source


  • verifiability
  • Scalability
  • fault tolerance
  • performance degradation (gracefully, hopefully)
  • update (hardware and software)


By the way, these are all the reasons why I like Service Bus (ESB)!

0


source


EDIT . Since the question has changed in emphasis, I edited my answer as follows.

Architecture and architect are heavily overloaded terms. First, you need to indicate whether you are talking about a software company (where software is a product / service) or a business company (where software supports a product / service).

There is also a top view of architecture (which matters from an organizational perspective) versus a bottom-up view (which matters from a project requirements perspective).

In a large business company, the architecture from a top-down (organization) perspective is usually divided like this:

  • Domain architecture , sometimes referred to as business architecture. For example, an understanding of merchandise trading processes and associated IT systems.
  • Data . For example, understanding descriptions of data in storage and data in motion; descriptions of data stores, data groups and data items; and mapping data artifacts to data qualities, applications, and locations.
  • Technical . For example, understanding the structure and behavior of the technological infrastructure of an enterprise, solution or system.

My areas of architecture from a bottom-up (requirements) perspective look something like this:

  • Correct use of middleware - loose coupling, fault tolerance, targeted transformations, killing between two points, etc.
  • Identify and develop as much reconciliation as possible.
  • Identifying and developing as many two keys as possible.
  • Identification and development of as many manual processes as possible.
  • Identification and development of any solution for end users - for example, Access to databases, Excel spreadsheets.
  • Identifying and designing any end-user edit "response" - getting information after all the work is complete and then editing it.
  • Exploring the complete data lifecycle: who owns it, who enriches it, who disseminates it, the only version of the truth, eliminates reconciliation.
  • Determining performance and scalability metrics, testing hazardous areas against multiple data profiles.
  • Identify processes and interfaces in real time and batch operations and eliminate batch dependencies wherever possible.
  • Consolidate on a single platform where possible, and single or multiple instances.
  • The ability to quickly handle new vanilla businesses and new complex businesses within a reasonable time frame.
  • Define a clear support model, especially in the regions where it is needed.
  • Public Maintenance and Recovery - How well can you recover daily handling and interface crashes.
  • BCP / DR requirements and capabilities, overall resiliency, WAN dependencies.
  • Where can the project risk be mitigated?
  • Security, access to end users and developers, a steel ring around production.
  • What are the MI reporting tools?
  • Emphasizing simplicity as much as possible, system commissioning.
0


source






More articles:


All Articles