Link: https://clausthorsen.wordpress.com/2015/02/19/solid/
From Claus Thorsen
So many IT departments seems stumble around in the dark, not having a structured overview of the application landscape or the business, and yet Enterprise Architecture promising to remediate this has a hard time gaining traction. Why is this?
My conclusion is, that:
- Enterprise Architecture is not a well-defined discipline. Hiring an Enterprise Architect, you really do not know what results you will have 6 month later.
- Experience is required. Everybody knows this to be true when it comes to e.g. developers or project managers, and we know how to check the skill level. When it comes to Enterprise Architects, the field of work is huge and the EA-products broad, why you can get away with being vague. It is scary how many in spe Enterprise Architects have been hired based on unclear framework chatter. 6-month later, results are lacking, the manager is frustrated, and EA is denounced as an irrelevant discipline.
- Perfection is wrong – aim for pragmatism and value creation! The artifacts can always be at least 10% better. You have to start using your artifacts even though they are not finished (tip: they never will be!). Put it to use when it is better than not having it.
- General perception is that the Enterprise Architect just sits in the ivory tower. From my experience, this actually is true in surprisingly many cases. If you once hired an Enterprise Architect and did not get the intended benefits, you are not going back down that alley. The rotten (or immature) eggs are in fact polluting the entire EA discipline. You have to create clear and frequent value!
- EA books and education leads the student to think that the task is to instruct the CEO. EA products may well reach the CEO, but so will a gazillion other things.
- Frameworks and EA are synonyms. First question to the newly hired Enterprise Architect often is which framework is preferred. In my view, the frameworks are brilliant – as mental inspiration! But they are not good for actual implementation. EA should be associated to results – not to frameworks.
If EA is going to be a success, we need to have a clear role, simple to use and understand tools and products that are creating obvious value. The aim of the blog is to share my view, toolset and experiences. Join in and let us make EA “SOLID”
- Simple – easy to understand and do.
- Operational – clear role, transparent and work in collaboration with existing functions.
- LEAN – fast and frequent results.
- In-Demand – value-creating products.
In my view, the EA function is a strategic, analytical staff function. The core trade mark is the linkage between strategy, business and IT. Without IT it is not EA, but LEAN or business analytics. The close linkage to IT often means, that it is embedded in or start out in the IT department, but it may as well live in a general business function like e.g. Strategy.
Successful Enterprise Architecture can make a world of a difference to a department and enterprise. In fact, it may determine the general success or failure of the department or enterprise. With this blog, I will convey my experiences on what works and what does not. I welcome you and hope to see you back on the blog – next post focus will be on the system landscape – to many the first and most fundamental EA artifact. Join in and let us together make Enterprise Architecture SOLID!