EA Needs to Focus on Social Mobile Apps

Social. Mobile. Apps. These three words have become an essential part of our daily lives and every enterprise daily business model. Social is not only about our personal lives but also the professional and everyday work environment (think Facebook vs. LinkedIn for example or other enterprise software that has its own chatter or collaboration tool). Mobile needs no introduction; when was it the last time you bought or was planning on buying a desktop?! Apps have become part of our daily personal and professional lives. Everything has an app! Take a ride on the NYC subway and you will see app ads from food delivery, laundry services, storage, to banking and medical services. Visit San Francisco and you will feel like Alice in Wonderland of the Apps!

EA approach to enterprise wide initiatives and projects must take this into consideration to be successful and design for the present and future. The mindset should endorse and champion this emerging pattern of trying to create social mobile apps for the business processes embodying a compilation of various components or assets that work collectively to perform a set of functionalities. This means the EA team needs to focus on components and artifacts that relate to interoperability, performance and scalability, reliability and availability, application lifecycle management, technological and security risks, and other related topics. Notice how Cloud and API relate and address all of these points almost instantaneously. This brings these two technological key components to the front and center of future implementations. It is also important to keep in mind that applications architecture is about design and managing multiple applications in the world of apps and how they are to operate together as needed for the different personas of the business and customers. EA team needs to go beyond the technology of software and hardware to include the social aspect so that the approach to architecture would be socio-technology architecture covering a design for the Person-IT and Community-IT. Finally, mobility needs to be stacked on that as a core strategic initiative with the idea that IT is designing for the mobile future of the different business processes.

References:

Mads Soegaard, Rikke Friis Dam (eds.). (2014). The Encyclopedia of Human-Computer Interaction, 2nd Ed. Chapter 24: Socio-Technical System Design (Brian Whitworth and Adnan Ahmad).

EA 872 Week15: The Cost of Ineffective Foundation for Execution

For any enterprise, a good effective foundation for execution is an important aspect of a successful EA initiative. The cost of ineffective foundation for execution can not only spread incompatibility and multiply effort, but also prove to be an obstacle for business agility and growth initiatives. Ineffective foundation for execution can be observed in multiple cases ranging from running the daily business to new growth initiatives, and many cases of business silos, IT bottlenecks and more. 

For example, getting different answers or metric results from different groups within the same enterprise for the same questions implies silos, duplicate efforts, mistrust, confusion and even conflict of interest. It is absolutely a disaster for the top executive management not to trust numbers and facts presented by business and IT, and this will lead to annoyance and blame war between the two. Another case is the hindrance of business agility when companies undergo growth initiatives to develop new products or as a result of mergers/acquisitions. Hindrance in this case results from the rigid structure of the different LOBs and IT silos not being able to contribute to agility and adapt to changes in the market in respond to evolving trends. Also, anytime IT is considered as a nuisance rather an asset or strictly a cost center, the general result is multiple bottlenecks blamed on IT consistently through times of change or strategic projects implementation. Other obvious indicators of ineffective foundation for execution are cases when data is duplicated in different systems, same processes repeated in different LOBs, and information needed for running the business across the enterprise is not readily available. 

All of these bear a hefty cost to enterprises and endanger the future survival and growth of the business. In addition, effective foundation is especially important with the current need for each enterprise to digitize capabilities and internal processes, and to capitalize on the value of data leading to IT becoming a strategic asset in itself and not just a cost center.

References:

Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, Mass.: Harvard Business School Press.

EA 872 Week14: Why EA Performance Management is Important

As EA872 class approaches the last few weeks bringing this long series of blogs to the final few, one recurring theme I have subconsciously reiterated multiple times is the importance of EA in these times of digital changes, and how the prospect of IT being an asset driving revenue rather than a cost center is increasingly important for the business to understand and adopt.

I was part of a customer workshop recently - predominately with the IT leaders of the enterprise. Of the many conversations we had, one statement that stuck with me was that “the executive business leadership still looks at IT as a cost center with the expectation of a CIO to mainly lower cost and increase efficiency”. The IT leaders, on the other hand, were saying “we have so much to give to the business; let us help drive value from IT, from data and benefit from the rise of digital business technology”. This made me think of the importance of EA to bridge that communication and trust in value gap between the two organizations. 

Specifically, having a performance management EA plan with a set of metrics that can be used to show the business the increased value of the EA investments would be a huge payoff to change that perception of IT. Once chosen, this set of metrics would be mapped to the strategic or vision statement of the enterprise. In other words, the metrics will measure the performance set of activities, systems and processes that are translated from the strategic or vision statement.This way, these Key Performance Indicators (KPIs) would ensure track and exposure of progress and value. At a high level, the KPIs will be addressing the progress though four basic levels of architecture: Business, Information, Technology, and Solutions. Additionally, the KPIs will need to be presented within the context of what kind of value or progress is being observed. For example, running the business KPIs are different than growing or transforming the business.

Going back to the statements I mentioned above, EA team should use EA performance management toolkits, like the one referenced below from Gartner, to show that not only EA and IT can help running the business by lowering operating costs and increasing efficiency, but also presenting opportunities for growth by maximizing business impact (ex. data insights across silos), and even transforming business by maximizing revenue and business impact through new opportunities, market area, competitive intel and possibly new products.

Reference: “Gartner for IT Leaders: Developing High-Impact EA Performance Metrics ”, (Gartner).

EA 872 Week12: An EA Initiative for a Knight Rider Prototype!

For this week, I am going to blog about some rambling thoughts I had while driving on a long road trip recently. I had rented myself a nice late model luxury sedan equipped with latest technology gadgets and bluetooth streaming. Cruising on the highway, enjoying the drive, I suddenly had a strange “Eureka” moment. Now who of us , or at least of my generation, has not seen Knight Rider, the famous tv show, and fell in love with that car and especially the computer KITT! I remember I was a kid watching that show and was totally fascinated by the idea of having a car that not only has an Artificial Intelligence (AI) but also can auto drive and do all different AI related tasks. (Ok the turbo boost and the leaping jumps might have pushed it too far mechanically wise but hold on to that critique for the end).

The reason I’m mentioning all of this is because it just occurred to me at the moment that we have all the technology out there though in discrete pieces. We have the AI, think Siri, and much more. We have the auto driving car, think Google and again much more. So all what is needed is for someone to take the initiative to bring the two together and voila, we would have a real Knight Rider KITT!

So for the sake of adding some EA context to this subject, let’s imagine a task assigned to a new EA team for an initiative to build our Knight Rider from these two discrete businesses with different processes, products, and technology. One could argue that the approach is a standard EA approach to a model that supports merging the two companies products and resembles a migration from a diversification operating model to a coordination one. Another argument would go for a unification model since an AI needs to be able to assist in the info and general access to the knowledge pool for real scenario decision making (ex. an answer to an inquiry about a geo location or weather or other). At the same time, it needs to control the dynamics of the car drivability by not only relying on the sensors data but also drawing from all archived data from other cars data and other played scenarios both historic and enriched data. 

It is definitely an interesting idea and line of thought. I will try to expand on how this can be an interesting EA exercise in future blogs but for now, I will leave you with the thought that Knight Rider is probably something you will see in the near future, and instead of “ Knight Rider, coming soon to a theater near you”, it will be “Knight Rider, coming soon to a dealer near you” !

Reference:

Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, Mass.: Harvard Business School Press.

EA 872 Week11: Effect of Organizational Changes on EA

EA helps to establish the guidance and authority on changes needed to conduct and support the strategy decisions and strategic goals of the enterprise to go from current state to future desired state. Changes typically involve the business processes, information applications, data and infrastructure. In addition, EA can induce some organizational and leadership changes. These would be coordinated organizational change management efforts that are meant to introduce or initiate the EA program in the enterprise. Most articles and papers focus on this one way direction of induced changes from EA to the org. But what about the other way around? What happens when there is a forced organizational change from outside of the EA program as a result of management restructuring or new senior management?

This would be one situation when changes might be forced from outside the EA playbook and could effect the ongoing EA migration plans. For example,  if a new CIO or CDA joins the organization, it is typical for them to apply re-orgs and introduce changes both on managerial and projects levels. This will affect prioritization of projects, momentum and moral, and most importantly the EA established migration plans and established procedures. It would defintely help to have the enterprise with an EA program mature enough to overcome these unusual and less than typical situations. In enterprises of business silos and straddled technology stages of EA maturity, these changes will be most abrupt and expected since there is leeway and change authority for the new senior management to induce their own new decisions and fingerprints on desired success and achievements (in hopes for the good of the enterprise). In enterprises with optimized core and business modularity stages of EA maturity, the changes can be softened and even governed to a certain degree since the maturity of the EA program can serve as a protecting shield. This I believe is a valuable  benefit that comes with the increased stages of EA maturity, if not more, just as the likes of increased IT responsiveness, improved risk management, management satisfaction, and enhanced strategic business outcomes. 

I would love to hear your thoughts on this topic and if you can share some real world stories from experience on how senior management changes has effected (or not) existing EA initiatives and programs.

References:

Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, Mass.: Harvard Business School Press.

EA 872 Week10: Simplifying EA Modeling

One of the main challenges perceived by enterprises and different teams about EA is the amount of documentation associated with the practice, and the time and effort usually spent on producing the artifacts. While it is true that producing documentation is not avoidable, a successful EA implementation will take the simplified approach of producing limited number of pages or slides per domain and thus set limits and provides framework for the EA modeling strategy.

For example, taking the approach recommended by Gartner on EA Modeling Made Simple, producing one slide high level conceptual views on each of the current state, future state, gap analysis and migration plan, is definitely a recommended method to view a complete EA strategy for the area of focus. The one slide approach per topic helps prioritize the efforts on defining the EA documentation deliverables in the early phases of EA kickoff as something that needs to be delivered in a short period of time and as a first iteration of the key elements of change needed within that area. Producing multiple iterations of a one slide is an easier process during review meetings (vs. a documentation with large number of pages). Having everything, at a high level, on one slide helps focusing the attention and priority on the important items that need change and is a perfect segway for a brief and to the point gap analysis illustration. Additionally, this approach leaves the complex graphs and diagrams as add-ons or appendixes to the EA model, while the main effort of the team is focused on the summarized slides. Having the migration plan on one slide is another strength of this approach where it can be used as reference during conversations, and concentrates effort on how the projects will adhere and accelerate (if any) the migration plan.

In summary, simplifying the EA modeling exercise by mainly listing a one slide high level of each of the current state, future state, gap analysis and migration plan is a highly recommended approach to defining an EA model and should be considered by all EA teams at the time of EA activities kickoff. At the simplest level, it helps to eradicate the facade of heavy documentation efforts typical of EA teams, and helps to assure the different teams in the enterprise that the approach will be one of speed, agility and concise effort.

References:

"EA Modeling Made Simple: ETA Domain Strategy Example". Bruce Robertson. (Gartner, Dec 2006)

EA 872 Week9: The New Era of an EA Outside-Out Model

This week I was attending a conference, and one of the inspirational speaker sessions touched on the subject of how technology and digital information is changing the way enterprises do business. The old model has relatively been stable around the concept of either inside-out or outside-in with the customers/business on the outside circle and the organizations/solutions on the inside either pushing out products to consumers or creating products directly influenced by the customers demand. In the inside-out model, one designs a product and then pushes it out  hence shaping the market with that product. In EA, this a focused planning on internal interactions for better operational outcomes. In the commerce world, a simple example would be a clothing store department where the designed outfits and apparel are pushed to the store floor, and I as a buyer would walk in with my buying choices limited to the available merchandise and designed outfits.

However, in the era of digital business combined with social and mobile transformations, these models are undergoing a forced change. Now, we are being governed by an outside-out model where everything is influenced and determined on the outside with focus shifting away from the enterprise to that outer circle. For example, and following the scenario given above, let us consider the new social apps such as those that lets you dress your friends and automatically buys the different designs imposed on your picture by other people. Here, we are no longer bounded by what designs and products introduced by rather altering the offered solution itself (the designed outfit). This is an outside-out model driving a new business model and imposing a different perspective for EA planning or approach to an enterprise. With and outside-out model, the EA team needs to take a broader perspective of not only business and technology but also the customers and their circle of influence. We are living in a connected world not only through devices but also through a social fabric and media where there are unknown possible combinations of all those three affecting the ecosystem of an enterprise and the way EA team approaches the architecture task.

The implications and ramifications on EA of an outside-out model will be felt at multiple levels. The business needs to understand this model and translate to the EA team, and IT should expect more agility and diversity. EA team should accordingly plan to communicate and work with both to facilitate and sponsor a closer partnership for driving change and innovation because  “the times they are a changin’ “. 

References:

"Architecting the Digital Business – Gartner Symposium/ITxpo Q&A With Betsy Burton". Christy Pettey. (Gartner, Sep 2015)

"Algorithms Are the Game Changers in a Digital Business". Daryl C. Plummer. (Gartner, Mar 2016)

EA 872 Week8: EA and Managing Conflict of Interest

One of the future state architecture deliverables is the EA architecture principles matrix with the information and technology principles. This starts by first gathering the important EA architecture principles that the executives, stakeholders, and business agree to. The process will take multiple meetings over several weeks to come to a conclusion or an agreed upon list of the principles. I have blogged before about the core business diagram model and the importance of having that for these early discussion where it will help guide the conversations around the architecture principles.

Once that list is obtained, the next logical step is to get the information and the technology principles and build matrices where the common intersections are to be the focus area of the implementation phases and serve as a clear reference and guide the forward steps of the EA implementation.

During this time, as with any process management and scenarios where there are different parties conversing on a list of goals and principles, conflict of interest will arise and jeopardize discussions and momentum on getting the different groups on agreeing on a common list of objectives. This is why the activities above are not an easy task as experienced first hand. One of the major difficulties is addressing the varying needs and opinions of the different teams involved in the discussions which will differ - sometimes considerably - on what constitutes a principle, whether it is relevant to the matrix or not, and how it relates to other categories in the matrix. 

As with most of architecture activities, having templates or toolkits such as the Gartner toolkits for the EA initiative activities helps to achieve a baseline and a sample for the beginners or the un-initiated into architecture. In addition to the templates, EA team should provide a discipline of managing the views and the values that are of best interest to the enterprise, and at the same time, the EA team should be given the authority to enforce this discipline while understanding that it is acceptable to have those wide discussions in the initial meetings to write down and note down all the suggestions and different opinions in order to be addressed appropriately, and do the research if needed to provide reasons for dropping some principles off the matrix while keeping others. It is the job of the EA team to update the different members involved in discussion on the latest trends in information and technology and what is relevant to the future state with respect to the business principles because the EA team is expected to have that future domain knowledge of latest trends and development as pertains to the domains. This is important and might be another challenging task to gather the intel and address the questions and more importantly be able to argue back on what is being included and for what reasons. This is why the executive support and sponsorship of the EA team is important as will be showcased during this stage where in most cases, the EA team is still relatively new in authority and the possibility of clashing with the well established organizations within the enterprise.

"Business and enterprise architecture - match made in heaven". Amitabh Apte (www.bc.org/content/conBlogPost,  July 22, 2013)

EA 872 Week7: Data Stewardship

Data Stewardship is an essential part of any organization and should be included in the future state architecture activities. This is of significant importance since we are at an age where it is all about the data. We are in a continuous raging momentum of digital transformation of all businesses across all industries. This is giving data teams a greater leverage and visibility within the enterprise hence the importance of mapping architectural principles to data stewardship and engaging EA team accordingly.

Having an effective data stewardship is a guarantee for the quality and integrity of one of the most vital assets of the enterprise: the data. Data cycles such as generating, acquiring, managing, enriching, maintaining,migrating, and disposing of if any, are both business as well as IT shared responsibility with collaborated governance. EA can facilitate the discussions,lead and guide both parties on producing a reference mapping matrix to the architecture principles of the enterprise. To facilitate this exercise, the EA team should start with standard templates such as the Gartner toolkit which categorizes the data stewardship requirements into three. First is definition and scope covering topics such as the authoritative information source, the audit-able system, single storage. The second is the processes, responsibilities and usage of data listing responsibilities for enforcement, system of records, standards, data repository for analytics, etc…. The third category covers data integrity and system security including the data as an asset, disaster recovery, internal and external security, encryption, and authorization. 

Starting with these broad data stewardship requirements, an EA team can come up with a template to use in discussion with stakeholders and IT to map to the architecture principles thus completing another important artifact as part of the future-state architecture implementation activities.

References:

"Data Stewardship Is Everybody’s Business: Best Practices for Data Quality Management". Rado Kotorov (insights.wired.com,  July 21, 2014) 

"L04: Future-State Architecture: Implementation Level". Retrieved from Penn State EA-872 class material.

EA 872 Week6: Building the Future-Sate Architecture

During EA initiatives, one of most important steps is building the future-state architecture. Yet, this is also a hard step to achieve and involves lots of discussions, different meetings, and distilling the different ideas and requirements into some very important artifacts that need to be built. These artifacts typically describe the desired future state of the enterprise and include requirements of the business needs, principles to reference decisions of the architecture, and models on how the components of the EA will interact to deliver the business value.

EA team has to lead the development of the conceptual principles for the business, information and technology viewpoints pertaining to the enterprise. This is not an easy task as the core EA team has to take the high level architecture principles taken from the business team discussions w.r.t to the business context of the enterprise, then  engage in detail the implementation team (solutions),  technology team , and the EA governance team to derive suitable matrices that can be referenced to guide the decisions made  during the architecture implementation.  An output example would be mapping business architecture principles such as compliance to an information principle such as access to data, or mapping updates and modifications to data to the auditing capability.  Additionally, the same compliance example would be mapped to technology principles such as master data management of all data (ex. an MDD system applied to the data repository).

Conceptual process pattern is another artifact of the business viewpoint of the enterprise architecture that needs to be delivered. This is a diagram depicting the detailed level business process patterns that are necessary to support the enterprise business strategy. This diagram can be derived following discussions with the executive team, VPs, and architecture team  (information and business).

A process topology diagram is an artifact that shows how all critical processes of the enterprise follow the business functions and relate to the business anchor model chosen by the enterprise. It might take time and cycles of drafting and modifications, but the process topology diagram will provide a visual depiction of the strategic intent of the enterprise and business change requirements that helps as a reference and simply from a visual point to drive clarity on direction. 

An important element of what runs in each enterprise artery system is information. This is why an information flow diagram showing how information is consumed including the different attributes of the business is another important EA artifact. These diagrams can get tricky if there are too much flow-arrows on the diagrams and it might be helpful to track the details in separate flow diagrams for each unit while keeping the master information flow diagram at a higher level.

Another artifact is the application layer diagram that shows how all the enterprise different units can be consolidated including the future strategic view. This can also be supplemented by additional vertical hierarchy diagrams showing the applications domains and infrastructure domains and horizontal domains within each such as the application tools, application server, integration, database, storage etc… 

In summary, building the future-state architecture is probably one of the most consuming efforts as viewpoints need to be solidified and the enterprise requirements and capabilities need to be mapped out from the existing current state. It is recommended not to spend too much time documenting the current state and rather spend the time focusing on building the future-state architecture by delivering artifacts such as the above mentioned ones.



References: 

"L04: Future-State Architecture: Implementation Level". Retrieved from Penn State EA-872 class material.

"Enterprise Architecture Program Pitfalls: Don't Start With the Current State". Brian Burke, Bard Papegaaij, Dave Guevara. (Gartner, Jan 2011)

EA 872 Week5: EA and The Good to Great

It has been a while since I have felt the urge to read a book. I mean an actual physical book. I am so immersed in online activities and reading summarized articles that it just seems to be a more efficient way to acquire knowledge and read topics, trends and pearls of wisdom. However, when “Good to Great”* was brought up in last class discussion, I couldn’t help but get curious about it and where its content and ideas might sit with respect to EA practices if any at all.

In this book, the writer, Jim Collins with the help of the research team, identifies companies that were able to progress from the good to the great state and sustaining that state for a considerable time.  The process thoroughly combs the list, classifies companies, and finds out the foundations of what is needed or rather the characteristics  of a company that went from a good to a great level. Its interesting approach on analyzing the data and within what context, the companies themselves across different industries, the long period of time chosen for the study of a company, and cross matching different qualification criteria is definitely a well researched project promising the results to be detailed and indicative. I do have some comments on how the last five to ten years and the change in the continuum of social, mobile and internet might have affected the results and if any change to the criteria but I will leave that to another day. Today, I’m going to focus on what is identified as Level 5 Leadership in the book and how that might relate to what EA is about and why EA is important within this topic.

Level 5 Leadership is defined around a set of characteristics  including being a catalyst for transition, leading, setting standards, building for next success in the next generation and more. These basically define the executive who can take an enterprise to an enduring greatness level through a mix of professional will and personal humility. The idea that disciplined people, disciplined thought, and disciplined action within a flywheel from buildup to breakthrough to achieve greatness is a solid one. Extrapolating some of these finding to EA, one can find similar ideals and can draw a conclusion of why EA must be part of that flywheel process and a facilitator or a tool among many for the Level 5 Executive to use in making that transition from good to great. I will pick few examples. Consider setting up successors for even greater success. EA is all about building capabilities to facilitate the transition from current state to future state to achieve the goals and objectives of the leadership. This is neutral to who is managing the enterprise and it standardizes  the assets and strategies for continuing to build on success. Another one is diligence. It is important in EA to have a diligence and thorough approach to understanding the intricacies of the organization or enterprise, documenting the different requirements, artifacts, assets, business processes, key components and much more. Anyone who has been involved in EA whether it be the discussion with business and IT or building a repository of components and artifacts knows how much important it is to be diligent and detailed for the EA intuitive and practice to be successful. Same thing can be said about having standards and abiding by them. Last but not least, I like the mentioning of the tendency of Board of Directors to usually select famous or celebrity leaders from the business fabric rather than focusing on the needed character for the leadership level. This is a reminder of the countless scenarios where different LOBs within the same organization tend to go out and try to buy solutions for there specific business problems based on the dazzling effect of the new product(s) rather than consulting and having EA to build a solid assessment of the needs of the LOB to compare to the repository of existing solutions and software within the organization or the corporate software choice for that particular need. 

Back to my comment on how the last five to ten years might have effected any of the conclusions of the book, the one thing that is certain is that the dynamics of running a great company or getting a company from good to great are becoming more and more a challenging issue for executives and leadership. Reading the referenced book affirms my belief that EA is yet another important tool that is a must-have within a Level 5 type of leadership as well as a catalyst to getting to the future great state of the goals and objectives set by leadership.

References:  

 * Jim Collins (2001). Good to Great. HarperCollins Publishers Inc.

EA 872 Week4: The Importance of an EA Core Diagram

This week I would like to address the importance of core diagrams in an EA initiative. I have always been an advocate of white boarding or using diagrams to clarify concepts and relaying information in an easy and simple manner. This is especially important and helpful when one has a room full of participants from different business backgrounds and both technical skills and business acumen are not the same across the room. EA is no stranger to those meetings and situations where typically business and IT converge to come up with vision and decisions on future state of the organization.

To facilitate discussions and ensure governance, EA core diagrams showing the business processes, infrastructure, integration and standardization requirements of the adopted operating model of the company can and should play an important role.

This conviction stems from the fact that core diagrams and references help clarify the difference between EA and IT Architecture. EA core diagrams are conceived by addressing the high-level business processes and IT requirements for the organization operating model. Excluding technical information that span second and third detailed levels helps keep a concise focused message and great conversation catalyst by elevating the items of discussion to the core of how business operates and what is needed from IT to support that model.  This helps and comforts business who is used to seeing typical IT diagrams that don’t necessarily correlate immediately to processes and daily operating concepts with too much emphasis on standards, tech syntax, and descriptions. At the same time, while going through the process of completing the EA core diagrams, non IT resources can focus on transferring business domain knowledge and sort of educate IT on the operating model. This way, when IT attempts to come up with detailed architecture and application diagrams, the whole organization can avoid the typical scenarios of having non realistic or too much “ivory” looking documents and diagrams that are of no use. Having a shared EA core diagram helps both parties to understand and agree on the organization’s enterprise architecture. 

This is why encapsulating EA in a core diagram describing the operating model is a well worthy exercise in the initial conversations and meetings between business and IT. It is very helpful to have a simple one pager picture or diagram at a high level that is used to capture the business process, the shared data ,and the technologies which are all important part of the foundation for execution during EA initiatives. Typically, such core diagrams would include the important common elements such as: core business process, shared data driving core processes, key linking and automation technologies, and key customers. These  are highlighted  since it is crucial to have a clear idea of the chosen operating model elements and collaborate on the essentials and basic pillars of the business for the best approach to capturing current state and how to move to the desired future state. There are many basic templates available that can be leveraged to capture this information for any of the typical operating models such as unification, diversification, coordination and replication.  Keeping in mind that “Choosing an operating model forces a decision on a general vision”*, an EA core diagram complements this statement by showcasing that senior management needs to be involved in  the early EA discussion and approve the core diagram along with IT.  It is understandable that the first run over core diagrams will be tough exercise but as progress is achieved and the diagram gets completed,  everyone in the organization will realize the importance of having  it  and will be the reference for any future conversations or decisions to be made.  The core diagrams also encourage healthy debates early in the conversations, help to shake legacy thought,  and stir movement in the right direction that best serves strategic goals and objective of the future state desired. They are best at showing EA as the enabler of business objective by providing a common customer view, unified shared information, governance, redundancy reduction, and steering the production of new applications that convey to the desired operating model.

References:  

* Ross, J. W., Weill, P., & Robertson, D. (2006). Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, Mass.: Harvard Business School Press.

EA 872 Week3: EA and the Business

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).

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.

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.