When I was a small child, I used to enjoy watching a Japanese language program. Called Monkey, it was all about a disruptive monkey with a massive ego. The monkey was turned into immortal being that could shrink and grow and travel on a flying cloud. Punished by the heavens for its transgressions, it was traveling with a Buddhist monk called Tripitaka on a journey to recover holy scriptures. The program also included a water monster, a pig, and a dragon who was shaped like a horse. It was a thing of its time, and you need to have watched to understand. By now, you most likely think that I have finally snapped, but this rather oblique journey somehow got me thinking about IT architecture and the ability to scale.
I am a firm believer in simplicity of design, almost aesthetic in form. A design is built up from building blocks. A house will always have a door. It will have windows, a kitchen, bedrooms, etc. The numbers, sizes, look, and feel will vary depending upon scale, location, or personal choice, but the base elements remain the same. It is the same in IT design. When looking from five miles up, you should be able to recognize the elements of a design, whether it is for an SMB shop or one of the biggest global companies.
All such designs consist of authentication and access controls, storage, BC/DR, monitoring/analytics, entry points, and the like. This is the case irrespective of scale or location, whether on-premises, off-premises, public cloud, or even hybrid.
At the SMB level, authentication and access controls may be as simple as a basic Active Directory and a VPN for remote access, or an AWS or Office 365 login page. At the enterprise level, authentication and access controlls may be multiple levels of Active Directory and LDAP federated by Microsoft Identity Manager, coupled with various external access points, like Citrix NetScalar fronting a XenDesktop deployment, or other VPN or MDM controls providing secure access for mobile devices.
Storage could be a low-end Synology and an S3 AWS connection, Dropbox, OneDrive, or a metro cluster formed of multiple EMC VNXs. An architecture is a framework for making your decisions: it is your guide. It is not the design, but an integral part of the design; decisions are just a matter of scale and requirements.
When you create a design, all the building blocks need to be considered. This is true whether you are designing for Exxon, HSBC, a local firm of lawyers, or a hospital. Miss a building block, and your design will not function. The fact that your client may already have an array capable of accepting your design needs does not preclude your need to investigate that building block. You still need to understand if the current capacity is enough for your needs; if the array is capable of providing the IOPS; and if your array fabric, be it Fibre Channel, NFS, or iSCSI, can handle the bandwidth. The same goes for other building blocks: the lack of a requirement for remote access does not preclude the need to consider it. Remember, requirements change over time, and remote access to that app may be needed. Your design should consider how remote access can be provided to that environment or application. It may be that a simple published application in a Citrix farm or adding the application client to the gold image of your virtual desktop environment will suffice, but it still must be investigated.
Security must be baked in from inception, not a bolted-on afterthought. Trust zones, even at the SMB level, need to be considered and factored in. How is access managed? How are roles defined? Where is the data stored? What compliance requirements are there and how will they affect product decisions? Note I say product decisions, not design. This is because a good architecture is built with firm foundations and building blocks at its base. It is not about product selection: that comes later. It is about processes. Scale is just a design choice.