shyshka - Fotolia
Enterprise architecture has matured from a little-understood practice at Scottish Water a decade ago to a trio of teams that meet weekly and have the ear of the most senior levels of the business.
In this interview, enterprise architecture team leader Paul Douglas provides a glimpse of how the discipline has evolved at Scottish Water since the government-owned utility company forged a directorate to help steer its digital transformation efforts and investment decisions.
Douglas also discussed the ways in which an enterprise architecture tool can assist with digital initiatives. Scottish Water recently renewed its multiyear contract with Orbus Software after a roughly yearlong procurement process and review of enterprise architecture tools. Douglas says Orbus iServer's familiar Microsoft-based interface, the suite's breadth of functionality, the SaaS tool's strong alignment to Scottish Water requirements, and cost factored into the selection.
What was the impetus for Scottish Water to start its enterprise architecture practice?
Paul Douglas: A digital directorate had been created in early 2011, and there was a shift toward having a more senior place for the IT team. Also, IT and the business change aspect were more closely aligned with one another. It wasn't just about making sure the servers and the systems were in support. It was about actually using the technology to transform or to change the business.
The other thing, of course, was just understanding what we had. Because the company had been around for a number of years by that point, there were disparate versions of the truth, if you like, of what we had technologically. One of the foundational tasks I had in this role in the fall of 2013 was to do a current state assessment. I basically got all our technical architects, partners and specialists into a room. It was almost like pulling together the inventory of everything that was being managed by the digital team. We used tools like iServer to help us and to have a place to store all that. A lot of it was about cataloging and understanding what was there so that we could then do much more effective planning for the future. It was a fairly intensive effort for between four to six months for our small team to get our first cut of all that we have on the estate. Then, we established a process to maintain that going forward.
What have been the main benefits of having a formal enterprise architecture practice?
Douglas: The main value was in bringing the ability to understand the impact of change in transforming our business. If we were to change out a technology or a system, how did that affect the people or the organization and the processes? That was the vision, and it's taken us a good number of years to get to a point where we can really start to leverage that value.
The other thing we've used enterprise architecture for is to better understand the future direction of the business and how to interact with and build trust with that business as a digital team so that we could then build strategies and investment approaches for technology.
What's the structure of Scottish Water's architecture team?
Douglas: I work under the head of strategy and architecture. The team is part of the digital directorate. Within that team, there's the enterprise architecture team, the technology architecture team and our digital innovation team. Each of us has five to eight people who work within each team.
The enterprise architecture team deals with setting the digital strategy and the investment planning part of digital. What makes our enterprise architecture team unique is the triage activity that we carry out. As things come in, we employ our journey mapping techniques, for example, to understand where the business customers are trying to go so that we can then pass that to the appropriate delivery route. The other aspect of our work is investment planning, where we maintain the applications and technology roadmaps to understand the issues that might be coming up and determine the interventions needed to achieve our strategy.
Paul DouglasEnterprise architecture team leader, Scottish Water
The technology architecture team looks after around 300 main applications and the underpinning technology. They are the domain experts for different parts of the architecture. Some may specialize in infrastructure or servers, and others may specialize in specific types of applications.
The digital innovation team was formed about two years ago. They leverage the value from the new platforms that have been put in. So, with Microsoft 365 for example, some younger members of the team take the needs that have been identified in the business, and where possible, they'll use low-code or no-code tools to build either interim or even longer-term solutions that can add value very quickly for the business. They work in an agile manner. Anything that falls outside of that usually gets pushed to the portfolio team.
How does communication happen between the three teams?
Douglas: The three teams meet on a weekly basis with the head of strategy and architecture. In enterprise architecture, I work closely with the technology architects because we help enable the roadmap activity and work to understand where the vendors are at. With the digital innovation team, we identify things that can be done using the existing platforms. Then we work very closely with them to make sure that goes into delivery. So, there's quite a strong synergy between the teams.
What does an enterprise architecture tool enable you to do that would otherwise have been difficult, if not impossible?
Douglas: First is the management of our applications and technology lifecycles that underpin the roadmaps for outlining our strategy direction. This could be done using spreadsheets, but the linking together of all the various elements of the architecture, maintaining the complex relationships and the ability to communicate the resulting intelligence to drive decision-making would be a lot more difficult if we didn't have a tool like iServer.
The secondary area where it drives a lot of value for us is in process modeling. Large parts of the business, including asset management, manage their business process models within iServer. This allows us to understand the process impact of changes we are making in digital, providing insights into a much deeper level of intelligence about the impact of change. Otherwise what you're doing is going into a workshop or a series of workshops. You've got some whiteboards. You've got some clever people in the room. You would be starting with the knowledge from the people you happen to have there. What iServer does is augment that with a much more detailed, more complex reservoir of intelligence that can be brought to bear.
During your procurement and review process, what helpful trends did you see in enterprise architecture tools?
Douglas: Linking to other platforms was common across many of them. There's the ability to connect using APIs into different systems like ServiceNow and platforms like Microsoft 365 to make better use of the data that's known across the wider organization. The other area that we've seen some of them talk about is the capability within the toolsets to manage and assess risk.
Can you share any examples that show how the iServer tool has helped the business?
Douglas: Every six years, we do a regulatory forecast of what our investment needs are likely to be over the next period. We've used iServer now twice -- for the period starting in 2015 and the period starting in 2021 -- to inform the investment initiatives needed to maintain our applications and technology. It also helps us understand the impact on people, on process, on data and how it links back to the overall vision, strategy and goals of the organization to ensure the digital investment plan aligns with where the business is going as a whole.
Scottish Water has now taken a different approach to how it plans investment. It does it in a more collaborative way with our stakeholders, the government, regulators and customer groups. We worked with our board and our senior executives to come up with what we call a management approach to digital investment. To create that management approach, we had to first understand the different elements of our IT architecture, the quality of the data we have and the rules around how we're going to invest. This is where enterprise architecture has really played a key role.
Has iServer picked up any new capabilities that have been especially beneficial over the years?
Douglas: One of the things that we've put in is strategic portfolio management [SPM], which is a suite of business reports using Microsoft Power BI. These reports are driven directly from iServer. The advantage is that it makes enterprise architecture more valuable to the wider business. Another new feature we're keen to explore is the ability to make sure that only what is approved gets published to the iServer portal. Little things like that make a big difference because people who benefit from the system need to be able to trust what's there.
How many people use the iServer tool across the organization?
Douglas: We have 50 writeable users and about 1,000 portal users. We also have 120 licenses for portal contributors to update attribute information within the portal. That means you can use the workflow capability within the system to allow people to make and approve changes to architectural components without them needing a full writeable license. The SPM reports are pushed through Microsoft Power BI, widening the audience across Scottish Water.
Has usage of the tool expanded beyond IT over the years?
Douglas: We had a decision to make at the beginning: Should we stick with the traditional enterprise architecture in a darkened room somewhere and build models? We avoided that. What we wanted to do is create a wider ecosystem of users around the enterprise architecture toolkit. The thought was to identify where we could appoint domain owners for different elements of the architecture. For example, we have been working recently with our data and analytics team to invite them to do their data modeling within the iServer environment. We've also worked with wider business areas, like asset management, to help them to do their business process modeling within the enterprise architecture tool.
We've tried to federate that out as much as possible, with a good measure of success. But there are some potential obstacles along the way that need to be managed. One is that the more people you have involved, the more you have to keep retraining new users. The second problem is that you can end up with quite a lot of junk in there. So, you have to do periodic cleanups to make sure that what you're seeing and what you're connecting to is actually usable. As we move into this next regulatory period, we are creating a clean version of the repository. So, it's a balancing act. But we've always tried to keep the enterprise architecture tooling as open as we can within certain controls.
What are the most important lessons you've taken away from your work in enterprise architecture?
Douglas: For me, the big one would be to make sure that you don't neglect the relationships with business leaders and colleagues across the wider enterprise. I've learned the value in having the conversations and keeping the dialogue going and, most importantly, being able to deliver value. For example, having the innovation team has been a big game changer for us. What tended to happen in the past was we would have three ideas of how to do things, but then it would have to go into a big monolithic change machine that would maybe take a year and a half to produce something. And, by then, the need was gone. What we now have is a much faster way of taking needs, identifying where we can add value, and then do something about it. That has been one of the big learnings for us. Make enterprise architecture real. Make it valuable. Don't live in a box building models.
Editor's note: The interview was edited for clarity and length.
Carol Sliwa has been a TechTarget senior writer since 2008. Her coverage area includes enterprise architecture, flash, memory and storage drive technology.