Designing Digital Retail (Part 5): The Role of Architecture
This is the fifth in a series of articles that explore how traditional retailers can move through the challenges of digital transformation. You can see all the articles in this series here.
The next post will explore how to build a data-driven business.
What does an Architect do in digital transformation?
Architects such as Enterprise Architects, Data Architects and Technical Architects have a central role to play in orchestrating digital retail (Dingsoyr & Moe, 2014). They do this through coordinating development efforts, advising about the necessary capabilities of the infrastructure, encouraging inter-team coordination through building knowledge networks and ensuring that there is continuous feedback between teams and portfolio managers.
According to Ross et al., (2006), the role of Enterprise Architecture is to develop “the organising logic for business processes and IT infrastructure, reflecting the integration and standardisation requirements of the company’s operating model”. In other words, their role is to ensure that the technology and applications used by the business are fit for purpose to achieve the aims of the business. Gartner (2019) suggest that a key role of The Architect is to provide continuity between the strategic direction of the business and the strategic direction for the information systems that support that business.
A number of standardized frameworks have been developed to enable Enterprise Architects to carry out this task. The TOGAF framework (Open Group, 2006) is currently the most pervasive framework, containing principles and tools for designing, implementing and governing enterprise IT architecture. It also contains a standardised visual vocabulary that architects can use to describe information systems and software in an organisation. TOGAF is divided into four pillars which represent the four architectural domains (Desfray & Raymond, 2014). These are,
· Business architecture: which deals with the business strategy, goals, governance, organisational design and processes.
· Applications architecture: which deals at an organisational level with the structure and deployment of application systems in the organisation to enable business goals and business processes. This domain deals with integration problems.
· Technical architecture: which deals with the underlying hardware upon which applications run.
· Data architecture: which deals with the organisations data storage, management, including both software data models and physical data storage.
Early attempts at Enterprise Architecture from 2005 to 2010 resulted in a considerable amount of criticism, with a study by Roeleven & Broer (2010) finding that two thirds of architecture projects fail. The authors cited lack of support from the senior management and lack of alignment between Enterprise Architecture and strategic decision making. As we have seen above, unless there is alignment between business and IT aims, it will be difficult to ensure that IT serves the needs of the business. Gartner (2012) found that Enterprise Architecture gets trapped in the IT department and therefore needs better methods of communication with the business, better ways to translate business needs into technical outputs, better insights into the human needs and pains of the end users and more holistic approaches to solving problems.
Making architecture work
There have been numerous developments in Enterprise Architecture in recent years, both in terms of technological innovations and in terms of how it is practiced which address some of these challenges. For instance, Service-Oriented architecture and Microservice approaches (Dragoni et al., 2017) breaks down software development into separate bundles of effective code (known as services), that can be called upon by other applications in the enterprise using a standardised communication protocol to enable integration between applications, even if they are built using different frameworks and programming languages. This is known as an Open Architecture approach. In retail organisations, services include product management, price management, supplier management, warehouse management, locations management, staffing management, promotions management, customer loyalty, customer identity, financial management etc. Services will be built by product teams during the development of their applications. Once built, the service can be called upon by another application being built elsewhere in the organisation.
It is necessary to manage the dependencies of the different products on these services in the most efficient way possible. This dependency management presents considerable challenges to architects and technology leaders. These individuals must manage the complexity of simultaneously developing products and managing the organisation’s technology infrastructure. This requires both visualisation techniques, such as blueprints and plans, and methods to improve communication, particularly between the business and the technologists. Furthermore, Architects tend to be technologists with background in information technology and information systems. They therefore have relatively poor understanding of the end-users, or the business needs.
Finally, there are also questions about how Enterprise Architecture fits in with more iterative and evolutionary approaches to technology management, which are becoming the norm, including Lean Enterprise (Humble et al., 2015) Agile (Pilcher, 2010) and DevOps (Kim et al, 2016). These approaches are manageable in small teams and organisations but become challenging at scale. Therefore, organisations need to develop methods to become better at communicating and managing complexity across teams. They must be able to facilitate co-creation activities between multiple stakeholders. They must also become skilled at prototyping and testing in a low cost, iterative, agile way, rather than planning and executing the entire organisational architecture from a blank sheet.
Up next: Designing Digital Retail (Part 6): Building a Data Driven Business
References
Desfray, P., & Raymond, G. (2014). Modeling enterprise architecture with TOGAF: A practical guide using UML and BPMN. Morgan Kaufmann.
Dingsøyr, T., & Moe, N. B. (2014, May). Towards principles of large-scale agile development. In International Conference on Agile Software Development (pp. 1–8). Springer, Cham.
Dragoni, N., Giallorenzo, S., Lafuente, A. L., Mazzara, M., Montesi, F., Mustafin, R., & Safina, L. (2017). Microservices: yesterday, today, and tomorrow. In Present and ulterior software engineering (pp. 195–216). Springer, Cham.
Gartner (2007) Gartner Enterprise Architecture Summit: Architecting the Agile Organization, 26–27 September 2007. Overview on www.gartner.com. Accessed November 18, 2013.
Humble, J., Molesky, J., & O’Reilly, B. (2014). Lean enterprise: How high performance organizations innovate at scale. “ O’Reilly Media, Inc.”.
Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook:: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution.
Jonkers, H., Lankhorst, M. M., ter Doest, H. W., Arbab, F., Bosma, H., & Wieringa, R. J. (2006). Enterprise architecture: Management tool and blueprint for the organisation. Information systems frontiers, 8(2), 63.
Pichler, R (2010). Agile Product Management with Scrum: Creating Products That Customers Love. Addison-Wesley Professional
Roeleven, S., & Broer, J. (2009). Why Two Thirds of Enterprise Architecture Projects Fail: ARIS Ex- pert Paper.
Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Harvard business press.
