You have an IT architecture to evaluate, how would you?
This is a common task for all types of architects, from Software to Data to Infra to Enterprise to whatever Architect working in the field of IT, really.
Here are some criteria I suggest to take into consideration to sanitize each and every solution.
The number one criteria however above all is and will always be, is it fit for purpose? Does it fulfil the business aim? (=Business Architecture covered, yes or no?)
Still, let’s go through some hard/soft criteria as follow.
Cost (Open: Project scope or RB scope?)
- Infrastructure Cost
- Operational Cost
- Development Cost
- Integrations Cost (e.g. integration with existing SAP Systems)
- Data Transport Cost
- Technical Availability
- Availability of Skills / Resources
- Risks / Maturity Levels
- Project Phase / Project Maturity: Explore, Scale, Phase Out, etc.
- Regional Availability
- Regional Privacy Acts
- Compliance (Personal Data, Data Security Classes, Data Privacy)
- Compliance to HIPPA, ISO27001, PCI
- Time to market / Lead time
- Export Control — can you get hold of your data, code anytime you want?
- Elasticity (fixed vs. dynamic sizing, predictability of workloads)
- Synergies / side effects to existing systems / decisions
Now you might think this is already a lot to look at, but no — we can drill deeper:
Now this is all on a high level, to really make a call there should be some additional pointers provided:
- Costs, and therefore “fit to budget” as that is a project reality in most firms?
- Dependencies in terms of other projects, deliverables
- Available knowledge internally and maybe externally, given e.g. aspired time frames and maybe budget as well in case the knowledge needed is very rare
- Already taking into consideration the impact on the Change Management initiative which should be kicked off anyway with every significant change
- Fit to overall Architecture Vision and Architecture Principles
- Process Complexity — less is always better because more maintanable!
- Product Roadmap / Development — is there any, what does it take away?
- Impact on User Experience?
- Embracing ‘work smarter not harder’, therefore including controls for automated exception handling, automated workflows?
- Regional Availability
- Elasticity and scaling limitations overall?
- Consumption based payment or flat-fee? (Depending on the case one or the other can be more beneficial.)
- Operations: Who is going to run it, what’s the Operating Model? Eg responsibilities between different vendors and service partners, SLAs granted
- Best possible use of existing reference architectures, adherence to Architecture Principles
- The risk section that is mentioned in the docs above needs to incorporate as well pointers to tactical AND strategic risks, e.g. if you do not this and that it might bite us in the long run because…
- References to lessons learnt — why gather learnings if you don’t act on them?
- Architecture Debt assessment: what kind of debt are you creating, what kind of debt are you boosting with the new solution(s)? Debt is inevitable, however you can certainly increase debt to higher or lower extent.
I hope you find this useful, feel free to chime in.
