What exactly does being an Architect mean? What do we do? Where does it lead?
As with any profession or practice, there are many definitions, perspectives, and schools of thought surrounding the concept of what an Architect is and Enterprise Architecture, as a practice, isn’t even thirty years old, so the mid-life crisis of definition is well and truly rife.
The concept of Architecture has grown from being just a set of small pilots to being a fully sponsored and supported initiative within IT Departments. With the growing demands to reduce costs, increase agility, and standardize (IT) environments, there has been a surge of architecture activity. Further, it has expanded its reach as business recognises that this is not a purely technical domain but is designed to meet the greater demands of the business and thus the overall Enterprise.
Yet the resistance of those early days of implementation still exist. The same questions are still echoing in the same hallways – engineers still ask why do we need architects? Project managers still argue that they are the train drivers and not just the conductors. FOs still perceive that architecture is an overhead and can struggle to justify its value whilst business managers think EA is an IT discipline that is aiming for a land grab.
For those of us who work for solution integrators or providers of outsourced offerings, we are stuck between two worlds – client and employer – both who seem to think that the investment in discipline and value should be made by the other.
Ignoring the client view of the world for the moment – I wanted to focus on the initial opening — namely – What are the architecture disciplines? But most of all, within the scope of an organisation – where does it lead?
In my fledgeling steps in capability space, I think it’s important to determine the answer to these questions to be able to map out Career, Development, Progression and Succession plans within my own organisation and perhaps even out into our clients and the industry at large.
As a primary step towards this, I have put together a basic discipline map. Now, I have seen a few different models – and as one colleague said, “they all make sense from their perspectives”. This is not intended to replace any other model nor be an all inclusive representation. It is intended to be a way to start a conversation and start the process of mapping out the pathways.
By all means, feel free to disagree, provide suggestions, guidance or ask for my Visio file and modify it to send me a new version. As stated, this is merely an opportunity to collate and manage the conversation.
Later iterations, I hope, will highlight the specific roles and their location within the industry structure(s). I also hope to collate a definition for each role – inclusive of expected skills, Lominger (soft skill) Competencies, Certifications, experience etc. With these in hand, I hope it means people can utilise them to tie their own development and progression plans.
I’m seeking any collateral that people may have within these areas, including, but not limited to:
- Role definitions
- Skill Breakdowns
- Lominger Breakdowns
- Existing development and training plans
- Existing succession plans
- Analysis or correlations between the roles across the organisation and/or GDNs
Or just, you know, a good bout of rigorous discussion … or stunned silence.