"Enterpise Architecture as a Strategy"
Fabrizio Di Carlo
Chief Information Security Officer | Leading Cloud-Native Security, Compliance & Risk Management Strategies for High-Growth SaaS Companies in Europe
At the beginning of my career as Security Architect I didn't know exactly what Architecture meant, I was, and I still am, a technical guy trying to do things in the best way as possible and integrate stakeholders, processes and have an holistic approach to the matter; for the same reason, although I like security, I am feeling frustrated to work only on the security streams of the project and not on the overall approach (sorry for the digression.
A book that is was suggested by me at the time, and that I have mentioned today during an informal chat, is "Enterprise Architecture As Strategy: Creating a Foundation for Business Execution" by Jeanee W. Ross, Peter Weill, and David C. Robertson.
Although the book is from 2006 the principles are still the same (like in the technology in general, although a specific technology can be evolved or new the principles remain the same). So, I have decided to write a little summary, most likely as notes to myself.
What is Enterprise Architecture?
Enterprise Architecture as Strategy means your Enterprise Architecture (EA) is addressing two key challenges:
- Integration
- Standardization across the company
With an effective EA, a company can improve business agility, achieve higher profitability, reduce time to market, lower IT costs, improve access to shared customer data, lower the risk of mission-critical systems failures.
Foundation
In order to re-think a foundation for execution and creating an effective enterprise architecture the authors put down a 6 steps:
- Analyze your existing foundation for execution;
- Define your operating model;
- Design your enterprise architecture;
- Set priorities;
- Design and implement an IT engagement model;
- Exploit your foundation for execution for growth.
Highlights of the 6 steps:
Analyze your existing foundation for execution
- Identify digitized processes.
- Figure out which processes are mission critical transactions.
- Identify elements of IT that are world-class.
- Evaluate the reach, security, data access, and flexibility you need.
- Identify the strengths and weaknesses in your foundation.
Define your operating model
- Identify the processes that differentiate you competitively
- Envision your ideal customer experience.
- Determine how you want to grow (acquire or grow related businesses, expand globally, acquire competitors, offer more products and services.)
Design your enterprise architecture.
Map out the essence of your business – your foundation for execution (companywide business processes, shared data, key technologies, and critical customer interfaces.)
Set priorities.
- Highlight priorities on the core architecture diagram (the base that the future capabilities depend on)
- Align the project portfolio to match the enterprise architecture
Design and implement an IT engagement model.
Create a formal IT engagement model
- IT governance at senior levels;
- disciplined project management across all major projects
- linkages that ensure IT governance and project management reinforce each other.
Exploit your foundation for execution for growth.
- Plan to cash in on the benefits.
- Allocate generous funding for training and development.
- Align incentives so people are motivated to exploit the foundation.
- Encourage and reward creativity.
Connecting strategy to humane teams, process and technology for fast flow of value. Sooner Safer Happier Advocate, Team Topologies Advocate, VSMC Ambassador and nudger of systems 🤓
4yThanks for sharing, I do worry that EA is still very much out of touch with the current times in terms of product lead organizations with product management etc. The EA of days gone by doesn't help with agility, it helps consolidate and reduce diversity in many cases and unless we are enabling capabilities to work from UX perspective we end up rolling out things like ERP systems and miss the mark entirely. This is firmly where practices of decomposition / Conway's Law etc are crucial to not building monolothic architectures that trick the business into thinking things are simpler than they really are. People need to embrace complexity / systems thinking and understand things in that context - I see too many simple / glossy PPTs of executive level architecture which are not data driven and not grounded in reality. I like the idea of focusing on the glue / standards / integration patterns etc - that is kind of the lingua franca that a company / industry may use but you need to balance that with innovation and exploring new technologies that could materially disrupt the incumbents e.g. enterprise service bus / old school SOA etc.. vs event driven architecture / streams etc. I think where architecture can help is to offer guide rails and a minimum viable bureaucracy with the emphasis on business value over architectural purity. The power distribution and engagement of the old school architects is not balanced, this tired old stereotype of an all seeing / Gandalf type character choosing technologies for an organization when they haven't touched any code for 20 years can be quite dangerous. Gregor Hohpe more recent book - the architect elevator is brilliant and talks about the number of levels / floors an architect can traverse and I think that's a great concept for making sure traditional EA / CTO types spend time in both the C-Suite and the "engine room" staying grounded in reality. Additionally with product lead organization with professional product managers / leaders I see the role of EA becoming different to how it was in the past. The Product Managers should be driving a lot of application / product level roadmaps and EA should help enable them to deliver in a balanced way. I also see projects / programs taking a backseat to products, programs exist in many forms but directionally should be there to coordinate and facilitate rather than act as a top down / command and control funding vehicle to force teams into doing something that may not intrinsically add value to the customers of the product. Unless those "programs" come with patterns and ways of helping product teams, the work often ends up being delayed or confused cause by lack of strategic alignment. (this is where ideas like OKRs can help but even then linking the more traditional vision, strategy, goals with OKRs becomes more important than ever so that there is top to bottom and bottom to top alignment of strategy to execution and this is continually maintained and updated. // end rant ;) (please take my input as critique on EA rather than your post specifically, I do agree with some aspects).
Hi Fabrizio, i was not able to find the title 'Technology Strategy Patterns' by Gregor Hohpe. Are you able to please post a link ?
Architect | Technical Adviser | Enterprise Transformation living Blueprint & RoadMap
4yStrategy influence Enterprise Architecture. Always about connecting the dots. Strategy, EA and underlying technologies.
Chief Information and Technology Officer (CIO/CTO) at KPMG Switzerland
4yClassic ! Always a go to..
Retired from big tech. Not retired from riding the Architect Elevator to make IT and architecture a better place. Have opinions on EA, platforms, integration, cloud, serverless.
4yYes, it's a modern classic, I reference it quite regularly. Indeed makes a good sequence of books to read! :-)