Some Inconvenient Thoughts about Architecture
Alex Jouravlev
![Alex Jouravlev]()
Alex Jouravlev
Data and Enterprise Architecture veteran and practitioner with up to date strategic knowlege and hands-on skills in AI. Proponent and enabled of Data-Driven Enterprise. Everything Graph and Metadata
- Enterprise Architecture should include Diagrams understood by the highest executive level to be useful. If you don’t present to top executives, your ability to make a difference is significantly deficient
- Enterprise Architecture should go down to technical details to be efficient. “PowerPoint Architecture” is quickly proved irrelevant, and ignored.
- Producing effective Enterprise Architecture without asking questions to Business, Vendors, IT etc is not possible.
- Service-Oriented Architecture works beautifully, as long as it is done behind the curtain in response to very specific business demands.
- Well-defined abstractions are critical to providing close oversight without doing ridiculous amount of work.
- TOGAF knowledge adds value to a good Architect, however a person whose main achievement is getting such certification is not an Architect.
- If your Enterprise Architecture does not include costs, performance and other quantitative information, it is no more than a shot in the dark.
- Business Motivation Modelling and Business Capability Modelling work, if done so well it could be presented to top executives.
- Information Architecture should be incremental, as it will never be completed.
- A good Architect knows how to model Architecture, can start immediately and would re-factor on the fly if needed. People who demand weeks or months to figure out how to model Architecture do not know how to do it.
- Good Architecture Modelling software can be used full-speed a few days into the start of the project. Anything that cannot, is not a good tool for an Architect.