Gartner defines Enterprise Architecture (EA) as: "presenting business and IT leaders with signature-ready recommendations ... to achieve targeted business outcomes that capitalize on relevant business disruptions". In order to develop such recommendations, it is for the Enterprise Architect to constantly "Track and evaluate emerging technologies, and map them back to the business model to identify how they can create opportunities".
"Traditionally, [the] EA led strategy execution activities for the enterprise. However, EA has [since] shifted its focus to strategy design". Today, for strategy execution, we must look to Solution Architects that "combine guidance from different enterprise architecture viewpoints (business, information and technical)", to construct an enterprise’s IT ecosystem. The Enterprise Architect must instead "Work with [these] domain experts across IT to ensure that the underlying technology platform is ready"; why they must also "improve communication and collaboration across silos".
What is necessarily implicit in the role of Enterprise Architect, is significant expertise in those technologies upon which an enterprise depends; or shall soon depend. Should we take as an example an SAP-centric enterprise – which I shall define as an enterprise that depends on SAP products for over two-thirds of its IT solutions – it seems unfathomable that the Enterprise Architect in such a company could possibly "Track and evaluate emerging [SAP] technologies" – in order to "map them back to the business model to identify how they can create opportunities" – with only limited experience in SAP. Personally, I’m willing to admit that although I started back in 1996 with SAP R/2, I still feel somewhat overwhelmed today by the vast array of new technologies offered by SAP; despite over 20 years of exposure to SAP technologies.
Yet, it seems that many enterprise architects in ERP-centric organizations have little to no experience in the underlying ERP. In such cases, at least one of the enterprise’s Solution Architects is of necessity an ERP domain expert; an expert upon which the Enterprise Architect will utterly depend in order to present "business and IT leaders with signature-ready recommendations". In an ERP-centric organization, this would provoke a situation in which the relevant Solution Architect(s) becomes the true source of 70-100% of the Enterprise Architect’s technology recommendations; the later playing no more than a co-ordinating/administrative role. In such situations, the titular Enterprise Architect would in fact no longer meet the definition of ‘Enterprise Architect’.
To help visualize the roles of ‘Enterprise Architect’ and ‘Solution Architect’ in an ERP-centric organization, I have prepared a simplified Diagram. What the Diagram is intended to suggest, is that the need for Solution Architecture is significantly reduced in an ERP-centric organization: there is little to build either within the ERP, or in the Cloud. There is little to architect in third-party solutions.
Some readers are by now possibly wondering about the role of ‘Software Architect’; a term many have no doubt heard. I was also curious to learn more about this when I recently bought O’Reilly’s February 2020, Fundamentals of Software Architecture. In this Book we immediately learn that: "the industry doesn’t have a good definition of software architecture". This becomes quite clear within the first few pages, as their definitional MindMap includes an entire branch named: "Enterprise Architecture" (from which point it will be extremely difficult to recover).
One of the biggest points of confusion, I suspect, is that ‘Software’ is a mass noun: it refers to nothing in particular. ‘Software’ can just as easily be a reference to an IT ‘System’, as to a particular grouping of IT ‘Solutions’. Only a few pages later, it became clear that this very recently published Book is actually about ‘Solution Architecture’: "Some architects refer to software architecture as the blueprint of the system, while others define it as the roadmap for developing a system". Indeed, according to Gartner, a ‘Solution’ is exactly that: "a distinct system to ... solve one or more business problems".
In the same Book, we read that "Programming aspects such as code structure, class design, design pattern selection, ... are all part of the art of programming", for which no architectural guidance is required. That’s interesting, because in over 15 years of SAP development, I don’t believe I’ve ever met an ABAPer that could even name five design patterns. A large number of ABAPers refuse to code using ‘class design’ at all, good or bad.
The title of this Book is in fact most strongly suggestive of ‘Application Architecture’: the very domain of "code structure, class design, [and] design pattern selection". Unlike ‘Software’, an ‘Application’ does actually refer to something in particular. You can 'architect' an Application, but not a/an Software. As opposed to what is suggested in Fundamentals of Software Architecture, I would argue that the role of ‘Application Architect’ is absolutely essential to mentor such concepts as ‘design patterns’ (mentioned only 10 times in their 400 page Book on ‘Software Architecture’); something a junior developer can hardly be expected to even begin to understand in their early years of software development.
That said, the reason for which you will find no reference to ‘Application Architect’ in the Diagram, is because this very real role, has very little value in an ERP-centric landscape; such as an SAP-centric enterprise. This is exactly why most ABAPers will never ask themselves what design pattern is most appropriate when developing a new: SAPScript, SmartForm, LSMW, Function Exit, BAdI, Implicit Enhancement, WorkFlow, OData Service, etc.
To close the chapter on ‘Architecture’, I am apparently obliged to make reference to Martin Fowler’s 2003 Article, Who Needs an Architect? In this Article, Martin – Author of Patterns of Enterprise Application Architecture (2002) – makes a statement that stands out for me far more than any others I have read on the subject: "I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software design".
This statement motivated me to include a – technology-agnostic – Event Broker in the provided Diagram. There is no better or cheaper way "to eliminate irreversibility in software design", than using an Event-Driven Architecture. Unlike the ERP or Cloud decisions that will be made by the Enterprise Architect, an Event Broker also falls nicely within the remit of Solution Architects.
"Traditionally, [the] EA led strategy execution activities for the enterprise. However, EA has [since] shifted its focus to strategy design". Today, for strategy execution, we must look to Solution Architects that "combine guidance from different enterprise architecture viewpoints (business, information and technical)", to construct an enterprise’s IT ecosystem. The Enterprise Architect must instead "Work with [these] domain experts across IT to ensure that the underlying technology platform is ready"; why they must also "improve communication and collaboration across silos".
What is necessarily implicit in the role of Enterprise Architect, is significant expertise in those technologies upon which an enterprise depends; or shall soon depend. Should we take as an example an SAP-centric enterprise – which I shall define as an enterprise that depends on SAP products for over two-thirds of its IT solutions – it seems unfathomable that the Enterprise Architect in such a company could possibly "Track and evaluate emerging [SAP] technologies" – in order to "map them back to the business model to identify how they can create opportunities" – with only limited experience in SAP. Personally, I’m willing to admit that although I started back in 1996 with SAP R/2, I still feel somewhat overwhelmed today by the vast array of new technologies offered by SAP; despite over 20 years of exposure to SAP technologies.
Yet, it seems that many enterprise architects in ERP-centric organizations have little to no experience in the underlying ERP. In such cases, at least one of the enterprise’s Solution Architects is of necessity an ERP domain expert; an expert upon which the Enterprise Architect will utterly depend in order to present "business and IT leaders with signature-ready recommendations". In an ERP-centric organization, this would provoke a situation in which the relevant Solution Architect(s) becomes the true source of 70-100% of the Enterprise Architect’s technology recommendations; the later playing no more than a co-ordinating/administrative role. In such situations, the titular Enterprise Architect would in fact no longer meet the definition of ‘Enterprise Architect’.
To help visualize the roles of ‘Enterprise Architect’ and ‘Solution Architect’ in an ERP-centric organization, I have prepared a simplified Diagram. What the Diagram is intended to suggest, is that the need for Solution Architecture is significantly reduced in an ERP-centric organization: there is little to build either within the ERP, or in the Cloud. There is little to architect in third-party solutions.
Some readers are by now possibly wondering about the role of ‘Software Architect’; a term many have no doubt heard. I was also curious to learn more about this when I recently bought O’Reilly’s February 2020, Fundamentals of Software Architecture. In this Book we immediately learn that: "the industry doesn’t have a good definition of software architecture". This becomes quite clear within the first few pages, as their definitional MindMap includes an entire branch named: "Enterprise Architecture" (from which point it will be extremely difficult to recover).
One of the biggest points of confusion, I suspect, is that ‘Software’ is a mass noun: it refers to nothing in particular. ‘Software’ can just as easily be a reference to an IT ‘System’, as to a particular grouping of IT ‘Solutions’. Only a few pages later, it became clear that this very recently published Book is actually about ‘Solution Architecture’: "Some architects refer to software architecture as the blueprint of the system, while others define it as the roadmap for developing a system". Indeed, according to Gartner, a ‘Solution’ is exactly that: "a distinct system to ... solve one or more business problems".
In the same Book, we read that "Programming aspects such as code structure, class design, design pattern selection, ... are all part of the art of programming", for which no architectural guidance is required. That’s interesting, because in over 15 years of SAP development, I don’t believe I’ve ever met an ABAPer that could even name five design patterns. A large number of ABAPers refuse to code using ‘class design’ at all, good or bad.
The title of this Book is in fact most strongly suggestive of ‘Application Architecture’: the very domain of "code structure, class design, [and] design pattern selection". Unlike ‘Software’, an ‘Application’ does actually refer to something in particular. You can 'architect' an Application, but not a/an Software. As opposed to what is suggested in Fundamentals of Software Architecture, I would argue that the role of ‘Application Architect’ is absolutely essential to mentor such concepts as ‘design patterns’ (mentioned only 10 times in their 400 page Book on ‘Software Architecture’); something a junior developer can hardly be expected to even begin to understand in their early years of software development.
That said, the reason for which you will find no reference to ‘Application Architect’ in the Diagram, is because this very real role, has very little value in an ERP-centric landscape; such as an SAP-centric enterprise. This is exactly why most ABAPers will never ask themselves what design pattern is most appropriate when developing a new: SAPScript, SmartForm, LSMW, Function Exit, BAdI, Implicit Enhancement, WorkFlow, OData Service, etc.
To close the chapter on ‘Architecture’, I am apparently obliged to make reference to Martin Fowler’s 2003 Article, Who Needs an Architect? In this Article, Martin – Author of Patterns of Enterprise Application Architecture (2002) – makes a statement that stands out for me far more than any others I have read on the subject: "I think that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software design".
This statement motivated me to include a – technology-agnostic – Event Broker in the provided Diagram. There is no better or cheaper way "to eliminate irreversibility in software design", than using an Event-Driven Architecture. Unlike the ERP or Cloud decisions that will be made by the Enterprise Architect, an Event Broker also falls nicely within the remit of Solution Architects.
- SAP Managed Tags:
