[FourthProtocol]

Admittedly I'm a greybeard. Wrote my first app in 1984. Moved through the ranks, from support to dev roles, application architecture, enterprise architecture and finially process optimisation.

And so wow, those diagrams in the links - how does one even manage all those boxes?!?

Architecture is easier than coding, if you stay away from more/bigger/but_my_app_is_a_special_little_snowflake mantras. Consider the age-old, tried, tested, proven architecture models of yore (other than their most excellent diagram notations, stay away from UML).

Architecture (design) is layered, not spaghetti thrown at a wall, hoping something sticks. Most (99.9%) software domains can be divided into three horizontal layers -

1. UI

2. Application/business layer

3. Data layer

(note that both internal and external service layers sit at the same level as data layers, allowing them to be called from the application layer)

Finally, there are vertical layers (shared across the initial three layers) These typically include -

4. Communication

5. Exception management

6. Security

7. Logs

Start with that as an overview/index of the entire solution, and when the beast needs to grow, just grow it. But grow it wisely. Use the standard 3-tiered architecture model. Re-use those cross-cutting concens in new applications.

Federate identities. Standardise access/permissions management.

Finally, don't feel compelled to use all the things - if the solution is services-based, don't code a UI for it. Simply connect your client to the relevant, existing service. Yes, services can be tiered, assuming your management processes are mature.

As to the management issue. Governance is what keeps your estate from turning into a hairball. Make extensive and judicious use of

1. Risk management

2. Change management

3. Stakeholder management

4. Design reviews

5. Project review (where team members grade managers)

Establish a technical design authority. The TDA concerns itself with broadly technical matters that facilitate a system-wide perspective. This might include -

1. Systems and solutions

2. Data

3. Communications

4. Quality objectives, including security

5. Development and development operations (devops)

6. Infrastructure (including but not limited to directories; networks; servers, both on-site and remote/in clouds; workstations and mobile devices).

7. Testing (Tools, techniques, platforms, languages and frameworks)

8. Locations

[tudorw]

Nice, thanks.