If you’ve read books such as the Dancing Wu Li Masters or are otherwise familiar with quantum mechanics, you have probably heard the idea that at its most fundamental level, reality does not exist until the observer interacts with it. At the subatomic level the very act of observing the world influences it - the same may be said for Enterprise Architecture.
A key skill for the Enterprise Architect is the ability to observe a complex system and describe it different ways according to the concerns of a stakeholder group. If you are a business person, you are interested in process, capabilities, benefits and costs. Software developers care about programming languages, component or service distribution, message queuing, etc.; while IT security is interested in preventing unauthorized access, keeping user audit trails, and protection of passwords. I could go on, but the point is systems can be described from different angles (IEEE 1471-2000 calls them Views, as does the Zachman Framework in reference to rows in the 6x6.)
While this is a great technique for description, I assert that the act of thinking about a system from different views actually influences the architecture.
Consider the elusive Integration Strategy. By that I refer to the problem of connecting things such that they exchange information seamlessly, cheaply and nimbly. The whole notion of SOA is an attempt to solve what started as an integration problem. If your view on this problem is focused on inter-application interoperability you probably are thinking about things like IBM’s Service Component Architecture as a framework for building applications. Not a bad idea.
Now, shift the perspective on integration from technology to business. First, the real problem is not that it is too difficult to integrate applications. That’s a subset of the broader issue - it is too expensive to access, maintain, and secure information required to carryout business. Furthermore, it is too costly to change processes in response to evolving business strategy.
This Business View may yield some different solutions than implementing an SCA. For example, you may ask why you have five processes that accomplish the same business purpose? Wouldn’t it be great if you could integrate those processes and have one that accounts for the variations in business context while maintaining overall integrity. You might embark on a business process improvement effort as a way to solve what at first looked like an integration problem. You may also ask why you need five different applications given a single future state process? You might go after application retirement and consolidation to reduce the number of required integration points.
Next consider a data oriented view - how come there are five different systems that maintain duplicative copies of the same product or customer record? This, you identify, contributes significantly to the same “integration” problems that too many process and applications did. Given this “ah ha”, you may latch on to Master Data Management as a way to solve the “integration problem” - in other words, you solve the problem by integrating data.
Please don’t get me wrong, the technical approach to application / data integration via SOA, SCA, etc. is still valid. My only suggestion is that a business and data perspective on the same problem may yield different, but complementary solution approaches. This is the heart of Enterprise Architecture - the ability to look at things both holistically, and from various views to come up with an architecture that is complete. Not fixated on a single solution to a perceived technology problem, EA should solve business problems with business solutions where technology plays a role.
Next time you find yourself staring a complex problem, wondering how you are going to solve it, put on a few different lenses and walk around the mess a few times. Watch reality change.
A key skill for the Enterprise Architect is the ability to observe a complex system and describe it different ways according to the concerns of a stakeholder group. If you are a business person, you are interested in process, capabilities, benefits and costs. Software developers care about programming languages, component or service distribution, message queuing, etc.; while IT security is interested in preventing unauthorized access, keeping user audit trails, and protection of passwords. I could go on, but the point is systems can be described from different angles (IEEE 1471-2000 calls them Views, as does the Zachman Framework in reference to rows in the 6x6.)
While this is a great technique for description, I assert that the act of thinking about a system from different views actually influences the architecture.
Consider the elusive Integration Strategy. By that I refer to the problem of connecting things such that they exchange information seamlessly, cheaply and nimbly. The whole notion of SOA is an attempt to solve what started as an integration problem. If your view on this problem is focused on inter-application interoperability you probably are thinking about things like IBM’s Service Component Architecture as a framework for building applications. Not a bad idea.
Now, shift the perspective on integration from technology to business. First, the real problem is not that it is too difficult to integrate applications. That’s a subset of the broader issue - it is too expensive to access, maintain, and secure information required to carryout business. Furthermore, it is too costly to change processes in response to evolving business strategy.
This Business View may yield some different solutions than implementing an SCA. For example, you may ask why you have five processes that accomplish the same business purpose? Wouldn’t it be great if you could integrate those processes and have one that accounts for the variations in business context while maintaining overall integrity. You might embark on a business process improvement effort as a way to solve what at first looked like an integration problem. You may also ask why you need five different applications given a single future state process? You might go after application retirement and consolidation to reduce the number of required integration points.
Next consider a data oriented view - how come there are five different systems that maintain duplicative copies of the same product or customer record? This, you identify, contributes significantly to the same “integration” problems that too many process and applications did. Given this “ah ha”, you may latch on to Master Data Management as a way to solve the “integration problem” - in other words, you solve the problem by integrating data.
Please don’t get me wrong, the technical approach to application / data integration via SOA, SCA, etc. is still valid. My only suggestion is that a business and data perspective on the same problem may yield different, but complementary solution approaches. This is the heart of Enterprise Architecture - the ability to look at things both holistically, and from various views to come up with an architecture that is complete. Not fixated on a single solution to a perceived technology problem, EA should solve business problems with business solutions where technology plays a role.
Next time you find yourself staring a complex problem, wondering how you are going to solve it, put on a few different lenses and walk around the mess a few times. Watch reality change.
Posts
No comments:
Post a Comment