Enterprise architecture sits at the intersection of business and IT.
It’s about making sure your business strategy is aligned with your technology.
It’s about determining how our clients can most effectively achieve their current and future objectives using the right IT systems.
Bridging the gap between business and IT
Enterprise architects are in demand to help bridge the divide between ever-changing technologies and business needs.
And how that is done has changed over time.
Enterprise Architecture has traditionally been centred in the IT space. It originated in the late 80's focusing on the architecture of the IT systems. But in the last 10 years the focus has shifted towards more business orientated techniques and methodologies.
For a long time, the link between business and IT was broken. The business often didn’t understand how IT worked. They might want something fancy but didn’t know whether it was possible or feasible. Sometimes it’s possible but it’s not feasible or too risky.
Now, new concepts such as business capabilities are used - where you first define what the organisation does. Then this gets projected to the IT.
IT shouldn’t tell the business what to do. Business needs to tell IT what to do. IT is there to realise the business services.
So the trend has shifted so that the language used to capture complex IT models are more meaningful for the business.
However, while we’re simplifying the language – the complexity is increasing. Many new themes have added requirements for EA to consider within its methodologies: Security risks are more serious and organisations must have a strategy for security; Data protection legislation locally and globally has put pressure on data governance needs; New technologies are emerging such as AI, IoT, Big Data, Machine learning, Blockchain. All these emerging themes which Enterprise Architecture must respond to adds new layers of complexity to the systems.
Working within an EA scrum team
I’ve been with Accenture since August 2017 and joined a major Government account. My role is a business analyst, often working within scrum teams.
A scrum team is a delivery team of roughly five to nine people under the supervision of a scrum master. Within the team are business analysts, testers and developers. My role is an analyst with a little bit of testing.
We conduct large scale agile delivery services which is continuous delivery of work for a client – such as taking care of different IT features or applications that the client has online.
Here’s how we work on a day-to-day basis: We might get a request from the client to look at something specific - for example enhancing an online functionality based on a business requirement.
A product owner will be in charge of that client feature and write a document brief for the scrum. As an analyst you go through the document and identify the dependencies, the risks and any other considerations. Because we work in an Agile space, dependencies might be other teams who have worked on this feature before.
The scrum has fortnightly “sprints” to go through our backlog of tasks. We break down the tasks, we prioritise them, we analyse the dependencies (eg do we need to engage the UX team to work on the user interface or do we need to engage web services), we give each task a development status and when it’s ready to be tested.
That very much simplifies the process but gives a gist of how a scrum works.
In a scrum roles are often interchangeable. Testers can do analysis and vice versa, or development work if they’re interested in coding.
In my current role I do a lot of the analysis of the web services and current existing architecture of systems. We define the current state of those models and look at what’s available and what needs to be changed because of new business requirements.
Then, we propose some changes and the teams that are in charge of those systems can make the changes.
Everything refers back to an overall enterprise architecture map. So we can pinpoint how any changes made to one part of the system might interrupt or impact the business - so if you unplug an app for example you will know the overall impact. It gives you a blueprint of the organisation and how it’s interconnected.
Desired skills for enterprise architects
Enterprise architects need to be able to communicate between the business and IT, have good leadership skills to help direct the business, and the ability to analyse and see the bigger picture to help design an architecture that changes as quickly as the business needs.
Anybody joining the Accenture enterprise architecture team will get training on Agile systems and technologies as well as the Design Thinking approach to tackling a problem.
As the complexity of IT grows so too does the need for a diverse set of skills to bring in knowledge and add value.