It is understandable that EA is often mistakenly perceived with an IT aura and the misconception that EA team is technical-talent focused with little business understanding. After all, most of EA programs are of technical background and/or within technical institutes and require the architect to understand the underlying information technology and the latest trends in software, hardware, and emerging technologies.
With the above statements in mind, my argument for this week's blog is that we are actually at a time where the boundaries between EA and business are much grayer than one would expect. The early twenty first century trends in technology (internet, communications, mobile, etc...) have brought a flood of information and capabilities to all sorts of people around the globe. When I recently saw a photo circulating online of a banana street vendor with a laptop on his cart trading stocks (yes it's true! just google it), I can't say I was completely surprised since not six months ago I saw my late fifty years old aunt overseas using a smart phone and throwing some mobile app names at me while looking up health information on wikipedia. So for EA team members to understand the organization business, terms, and processes, challenges and trends trends is something quite feasible and attainable within relatively short time even if their backgrounds is technical. Business should see EA as a strategic asset that can be trained to work in tandem to accomplish the strategic goals of the organization and maintain the success of the business. For example, companies usually have methodologies to determine strategy and future goals. EA team should be trained and educated on these methodologies. Same for the business operation of the organization. EA should be expected to learn and understand the different lines of business and the way business operates. This is a reason why the COO should be comfortable being approached by the EA team and expect them to be trained and educated on the operating model(s). Corporate performance can be learned by EA so that the team understands financials and corporate budgeting process. This allows EA to know the important aspects of data and reporting that are needed for producing performance metrics and what is highly recognized as success within the organization including EA team performance metrics to be put on paper (for ex. in the EA Charter Program). It is also good for EA to be familiar with marketing and how it maximizes the efficiency of the organization business model by being the voice of the customer. EA team can learn and identify the marketing functions to be savvy about the activities and processes to examine evolution and check effectiveness. Corporate governance domain is another area that is on the far end of technical skills spectrum yet EA team can get involved to understand regulations and compliance and be familiar with terms such as SOC, Sarbanes-Oxely, HIPPA, etc... A trained EA in corporate governance can be leveraged to design a process that manages all compliance from a top-down enterprise perspective. Another business exercise is the continuous merger and acquisition (M&A) which is the catalyst for increasing size and business and growing success. EA team can be trained to understand economies of scale, customer demand, and globalization effects on business. EA can spread education and provide feedback on effectiveness and efficiency of processes.
As the EA team gets trained and acquire skills in these business topics, business can start to realize the importance of EA to be educated in such fields with the expectations that it does not require a background in business or to be a lengthy process before seeing return from EA team and feedback to increase efficiency and successfully meet the strategic goals and objective of the organization as a whole.
Reference: “An Enterprise Architect’s Guide to Working for the Business”, Deborah Weiss (Gartner).
Sunday, January 31, 2016
Sunday, January 24, 2016
EA872 Week2: Why we need Foundation: A case of "Data Integration Gone Wrong"
This week I'm going to take a small break from the material and present a real case where not having a good foundation results in complex efforts to integrate data at the wrong place at the wrong time.
A company has multiple transaction systems tracking down contracts, campaign, and contacts for running down "ads" at different locations. Typically, this would be a straight case of integrating the data, finding the lowest grain, and rolling/aggregating as needed across the different hierarchies needed. The problem, in this case, is that each of the contracts, campaign, contacts, and locations appear to be at different grain levels with no clear joins or direct way to aggregate data meaningfully. After much exploration and tracking down how data relates from these different objects, it turns out that it cannot be joined in a conventional way because there are not enough integration points. Here is an example: one can track down the count of locations an ad was played, but the connection to contacts is only based on a pool of locations associated with a campaign assigned to multiple contacts. So you have the same count of locations to all contacts which does not make sense!
Simply put, the problem here is that as the business grew, there has been a disconnect of what modifications need to be done to integrate the different data silos coming from different business units so an effort to revising the foundation and consolidating these silos was not undertaken by the responsible teams. I can only deduce that there is no strong EA team or the EA architecture foundation has not been in place as the business grow and expanded. Hence, the typical scenario where one ends up with data silos that need to be integrated at the end of the data processing stages (user end) meaning the need of additional workarounds and quite often hybrid additional tools that need to be purchased and multiple implementation efforts (inefficient resource allocation). This is way EA is always important and needs to be the driving force behind coupling business goals and objectives to IT efforts and implementations especially in business integration scenarios (whether from acquisitions or from growing business units and functionalities).
One interesting approach I read about this week is in chapter 1 of Enterprise Integration Patterns:
http://www.enterpriseintegrationpatterns.com/patterns/messaging/Chapter1.html
Under Loose Coupling, the chapter discusses loose-coupling and tight-coupling with advantages and disadvantage of each approach. This is something the can be considered at an EA planning level or part of EA architecture foundation.
A company has multiple transaction systems tracking down contracts, campaign, and contacts for running down "ads" at different locations. Typically, this would be a straight case of integrating the data, finding the lowest grain, and rolling/aggregating as needed across the different hierarchies needed. The problem, in this case, is that each of the contracts, campaign, contacts, and locations appear to be at different grain levels with no clear joins or direct way to aggregate data meaningfully. After much exploration and tracking down how data relates from these different objects, it turns out that it cannot be joined in a conventional way because there are not enough integration points. Here is an example: one can track down the count of locations an ad was played, but the connection to contacts is only based on a pool of locations associated with a campaign assigned to multiple contacts. So you have the same count of locations to all contacts which does not make sense!
Simply put, the problem here is that as the business grew, there has been a disconnect of what modifications need to be done to integrate the different data silos coming from different business units so an effort to revising the foundation and consolidating these silos was not undertaken by the responsible teams. I can only deduce that there is no strong EA team or the EA architecture foundation has not been in place as the business grow and expanded. Hence, the typical scenario where one ends up with data silos that need to be integrated at the end of the data processing stages (user end) meaning the need of additional workarounds and quite often hybrid additional tools that need to be purchased and multiple implementation efforts (inefficient resource allocation). This is way EA is always important and needs to be the driving force behind coupling business goals and objectives to IT efforts and implementations especially in business integration scenarios (whether from acquisitions or from growing business units and functionalities).
One interesting approach I read about this week is in chapter 1 of Enterprise Integration Patterns:
http://www.enterpriseintegrationpatterns.com/patterns/messaging/Chapter1.html
Under Loose Coupling, the chapter discusses loose-coupling and tight-coupling with advantages and disadvantage of each approach. This is something the can be considered at an EA planning level or part of EA architecture foundation.
Thursday, January 21, 2016
EA872 Week1: The Foundation
Week 1: The Foundations
Reading through week 1 assignment and chapter I of the text book, I couldn't help but think of how lucky I have been in my career and how intuitive life analogies apply to work dynamics and business processes.
I have been lucky in my career to work mainly with growing technology companies applying, for the most, the latest agile and best practices in running the business and the organization units. So having a solid foundation to build strategy and an operating business model has always felt as if it goes without saying. The examples provided in illustrating the importance of a good foundation to execute strategy remind me of several clients I had dealt with during implementation phases of projects as professional services work: bringing advanced software solutions to business needs in ever changing landscape of technology and business processes. Some of these projects were successful in delivery and in results; others were painful exercises of introducing new tools to a land-mine field of complex and intricate silos of units and teams. In every successful project, the client had a good foundation for execution.
Life analogies always force themselves in common every day activities whether one is addressing a coding problem, integrating systems, analyzing data, or solving a business problem. The same way one needs foundations for learning a language, a tool, a human activity, the same way an organization has to have foundation for running its business. I was reading the example of walking and running (you need to walk before learning to run) and couldn't help but think of how in EA 871 where the basics of Enterprise Architecture described having the artifacts and components as crucial to successful EA. It is intuitive from life to have components and tools that you can leverage to use to solve or build even though they were not meant specific for that purpose (a far extreme example is using a long screw driver as a stethoscope on a car engine). The dynamic essence of life forces the the skill of adaptation and not volume or strength to be at the highest of importance (that's how scientists say we beat the dinosaurs!), and the same principle applies to an organization: the better the foundation, tools and resources, the higher the competitive edge, business value and successful longevity it has.
Thanks for reading these rambling thoughts and I truly welcome thoughts and comments. If you have made it to this line, I leave you with this article that I found this week (" http://blogs.informatica.com/2015/10/02/state-enterprise-data-business-problem/#fbid=qcdGz5je-Qr ") which is a perfect introduction into why EA is on the top list of my interests as it relates to data, analytics and cloud.
Reading through week 1 assignment and chapter I of the text book, I couldn't help but think of how lucky I have been in my career and how intuitive life analogies apply to work dynamics and business processes.
I have been lucky in my career to work mainly with growing technology companies applying, for the most, the latest agile and best practices in running the business and the organization units. So having a solid foundation to build strategy and an operating business model has always felt as if it goes without saying. The examples provided in illustrating the importance of a good foundation to execute strategy remind me of several clients I had dealt with during implementation phases of projects as professional services work: bringing advanced software solutions to business needs in ever changing landscape of technology and business processes. Some of these projects were successful in delivery and in results; others were painful exercises of introducing new tools to a land-mine field of complex and intricate silos of units and teams. In every successful project, the client had a good foundation for execution.
Life analogies always force themselves in common every day activities whether one is addressing a coding problem, integrating systems, analyzing data, or solving a business problem. The same way one needs foundations for learning a language, a tool, a human activity, the same way an organization has to have foundation for running its business. I was reading the example of walking and running (you need to walk before learning to run) and couldn't help but think of how in EA 871 where the basics of Enterprise Architecture described having the artifacts and components as crucial to successful EA. It is intuitive from life to have components and tools that you can leverage to use to solve or build even though they were not meant specific for that purpose (a far extreme example is using a long screw driver as a stethoscope on a car engine). The dynamic essence of life forces the the skill of adaptation and not volume or strength to be at the highest of importance (that's how scientists say we beat the dinosaurs!), and the same principle applies to an organization: the better the foundation, tools and resources, the higher the competitive edge, business value and successful longevity it has.
Thanks for reading these rambling thoughts and I truly welcome thoughts and comments. If you have made it to this line, I leave you with this article that I found this week (" http://blogs.informatica.com/2015/10/02/state-enterprise-data-business-problem/#fbid=qcdGz5je-Qr ") which is a perfect introduction into why EA is on the top list of my interests as it relates to data, analytics and cloud.
Subscribe to:
Posts (Atom)