Posts Tagged ‘Enterprise Architecture’

Full Stack Data Science. Next wave in incorporating AI into the corporation.

October 22, 2019

https://www.forbes.com/sites/cognitiveworld/2019/09/11/the-full-stack-data-scientist-myth-unicorn-or-new-normal/#1eb0d4f32c60

I like the concept of “Full Stack Data Science”, especially the way the author depicts it in the included graphic.

One thing I would like to point out is the recognition that the process is really a circle (as depicted) and not a spiral, or line.  What I mean by that, is the path does not close between what can be perceived as the beginning “Business goal” and the end “Use, monitor and optimize”.

The results of applying Data Science to business problems not only helps solve these problems, but actually changes the motivators that drive the seeking of solutions in the first place.  Business goals are usually held up as the ends with the lowest dependency gradient of any component of any complex enterprise architecture.  While this may be true at any point in time, the dependency is not zero.  Business goals themselves change over time and not just in response to changing economic, societal or environmental factors.  The technology used to meet these goals does itself drive changes to the business goals.

A party, whether person or organization, tends to do what it is capable of doing.  Technology gives it more activities to undertake and things to produce and consume, which then feedback to the goals that motivate it.

I think this article is one of the best I’ve seen in making that point.

 

Cross-mapping Business Data Elements with Physical Data Structures

September 12, 2018

Cross-mapping[i] business data elements (BDEs) from requirements or business glossaries all the way through to the physical data structures that store these data elements can be tricky.  This process is made easier if a logical data model (LDM) is implemented between the business side and the technology model upon which the physical implementation is based.

In this article I will show two styles of cross-mapping between the BDEs of the business glossary and the data storage structures defined in the physical data model (PDM).  The two styles are called “Column Style” mapping and “Cell Style” mapping.

Column Style can apply to the cross-mapping of BDEs with both base tables[ii] and reference tables.  Cell Style mapping takes Column Style a step further for reference data and maps the individual values of a reference BDE to individual cells, or row column coordinates, in the database.  If each reference value needs to be implemented in the technology separately a Cell Style mapping is needed.

Also some BDEs are atomic in that there is no inherent structure in the business data element.  I call these Simple BDEs.  Some BDEs have an inherent structure which depends on the scope of their business definition.  These structures are often in the form of a container and its contents.  I call these Compound BDEs.

Some examples of each style follow.  Figure 1 shows an example of a Column Style mapping of a Simple BDE[iii] to a single Column of a single base Table in the database.  Using the terms “Table” and “Column” gives the impression that these mapping styles apply only to relational databases.  This is not true.  The concepts here can apply to “NoSQL” databases as well, such as Key-Value Stores, Column Family Databases and Document Databases.  These types of databases have been referred to as Aggregate-Oriented Databases.[iv]

Figure 1.

Figure 2 shows a Column Style mapping of a Simple BDE to a single Column of a single reference Table in the database.  Note here that because it is a reference data mapping that the valid values of the reference BDE do not get specifically mapped to any structure or data in the database.  In this case the valid reference values may be defined and maintained in the business glossary in an appropriate manner but there is no explicit mapping link between them and any thing in the data model or database.  Also note that I am not saying that the reference values are not in the database.  They almost certainly are, since the applications would presumably not function properly if they were not.  But the values themselves (“Unknown”, “IFRS”, US GAAP”, etc.) are not considered BDEs.

Figure 2.

Figure 3 is a Column Style mapping of a Compound BDE to multiple Columns of a base Table in the database.  Note here that the BDE maps to two Columns in the same Table.  It could, of course, map to only one Column, or to many more Columns in many more Tables.  The point of this example is not how may times the BDE maps to various Columns but that it is a Compound BDE.  “Current Assets.Cash”[v] really identifies two business concepts, “Current Assets” which is a section of a financial statement, and “Cash” which is the most liquid kind of asset.  In terms of a financial statement, cash is a type of current asset.  For whatever reason, probably because cash itself can occur in multiple contexts, the business found it necessary to identify the financial statement use of cash in its own BDE.  Cash could also, for example, be a type of transaction, which would be another BDE.

Figure 3.

In Figure 4 we have an example of Cell Style mapping.  Here, the same Compound BDE that was used in Figure 3, “Current Cash.Assets” is broken apart into its two separate parts, and each is mapped with a different Column in a different reference Table in the database.  Both of these tables are reference Tables.  One contains the name of the types of financial statement templates used by the system (financial_statement_templates) to which “Current Assets” is mapped.  The other contains the names of the types of lines on those financial statements (financial_statement_line_templates) to which “Cash” is mapped.  It is unlikely that “Current Assets” would be mapped to multiple database Columns, but because of the multiple meanings of “Cash” there could be multiple mappings between it and multiple database Columns.

Figure 4.

Note that Cell Style mapping requires mapping to the data content of the database and not just its structure, or metadata.  This needs to be taken on with great caution and requires a consensus for how the words (e.g. “Cash”) used in the glossary are conveyed to and used in the Transaction Activity Data[vi] of the database to determine the actions of any application accessing the data.  Cash is simple, but any time you rely on reading a string to determine a code path you create an external dependency in the code.  However, if the business changes the name of a Cell Style mapped BDE there should be a documented path to where and how that value is used by any application that accesses it in the database.  This fact alone makes any system more maintainable and sustainable.

 

 

[i] The word “cross-mapping” is used to imply that the mapping goes both ways, from business to technology, and from technology to business.  This allows the documentation of the system to more accurately describe the entire enterprise architecture by creating valid and traceable links back and forth between the business architecture and the technical architecture.  By creating an interface between the two aspects of the enterprise architecture, business people can more confidently make decisions based on the data they see, knowing with confidence it is reliably stored and processed, and technical people can more confidently know the data they collect, manipulate and provide does in fact represent what business side intends for it to be.

[ii] I use the term “base table” here to refer to the realization of the bottom four of the six layers of data described by Malcolm Chisholm in his article “What is Master Data” originally published February 6, 2008.  http://www.b-eye-network.com/view/6758 .  These include Enterprise Structure Data, Transaction Structure Data, Transaction Activity Data and Transaction Audit Data.

[iii] The numbers (128, 600 and 1) that follow the name of each BDE in the examples are purely arbitrary and are there only to indicate that BDE’s should be numbered in the catalog for indexing purposes.

[iv] See Pramod J. Saladage and Martin Fowler, NOSQL Distilled, A Brief Guide to the Emerging World of Polyglot Persistence, Addison-Wesley, 2013.

[v] Note the “.” Between Current Assets and Cash.  This is just to make it easier the tell that the BDE is compound.  Don’t count on always having a separator between the parts of a Compound BDE.  The glossary tool may simply not support it or the in-depth analysis to identify the two parts may not have been made.  As a data modeler you may have to do this analysis yourself.

[vi] Please refer to note ii above.

 

A Simplified Enterprise Architecture Framework

September 4, 2013

An Enterprise Architecture Framework is an approach to aligning the multi-million (or billion) dollar investments that all large organizations (public and private) have made, and are still making in information technology, with the mission of the organization. An organization’s mission begins with its vision. A vision is described by David Hay, as a desired future state of the enterprise without regard to how it is to be achieved.[i]  Its vision is the synthesis of the ends that an enterprise sets out to accomplish and its mission is the means by which it plans to accomplish this vision. This can only be done successfully with an approach that emphasizes collaboration, planning, monitoring, analysis and action.

Business plans include all the ends the enterprise sets out to accomplish and all the means by which it plans to accomplish them. These include such objectives as goals to be met, opportunities to pursue, problems to solve, constituencies to service, expectations to satisfy, and how to increase the value of the company’s equity. Often these objectives are not initially stated in a way that can be measured. It is the mission of Enterprise Architecture to organize, structure and ultimately measure these objectives.

It is when the objectives of the mission are set in the environment in which an organization operates, including such factors as business locations, technologies deployed, functions performed, competitor and partner analyses, competencies, industry trends, and institutional knowledge that we begin to see the need for organizing, structuring and measuring the factors that influence the strategy of the enterprise in pursuing its mission.

But the most carefully crafted strategy is no more than words without the business processes and functional organization structure to carry it out. The more abstract aspects of the strategy need to be made actionable through less abstract processes and patterns of behavior that can actually be performed, and measured. To this end then competitors, partners, providers, regulators, customers, human resources and even the enterprise itself become the parties that are of interest to the enterprise. Do these factors make sense in the context of the mission? These are the factors that perform, constraint and regulate the carrying out of the mission. In short parties become the “Who” aspect of the enterprise.

In addition to the parties whose behavior influences the pursuit of the mission, all enterprises produce something they hope to be able to exchange for value with other parties. This, of course, is the enterprise’s product. In general an enterprise’s product takes the form of either goods, services, or some combination of the two to form more complex compound products. While most of the parties with whom an enterprise engages are outside of the direct control of the enterprise, the definition and pricing of products is typically under tight enterprise control.[ii] This is so as long as there is a clear value proposition for the product. In this modern post-virtual world an enterprise’s challenge is often to clearly define just what its products are and what its unique value proposition is. In many ways the product is the enterprise. Products become the “What” aspect of the enterprise.

Parties and products are not just naturally associated with one another. There has to occur some activity between the parties with the ultimate intent of producing, assessing or exchanging products between them. Each party must perceive there to be more value to themselves in the product they receive than the value of the product they give up in the production, assessment or exchange. Almost always one of the products given in an exchange is money, in the form of price or compensation.

These exchanges are the life blood of any enterprise. It is how the enterprise accumulates capital to enable it to grow, it is typically how “success” is measured, and at the most fundamental level it is how the enterprise pays its bills and remains intact and the master of its own destiny. Exchanges, then become the “How” aspect of the enterprise. These exchanges and the processes that implement them are how an enterprise accomplishes its mission.

With the virtualization and digitalization of so many traditional channels it is tempting to think that “location no longer matters”. I feel this would be a mistake however. Most of the parties an enterprise deals with, especially customers, still live in the “real world” or at least their virtualization can be resolved to real physical human beings and organizations of human beings who typically need or use a real address somewhere on earth. This is especially true of the customers you hope to reach (or constituencies you hope to serve), even if the address you associate with them is itself virtual like a “Facebook” or professional community or an e-commerce website. And, of course, the enterprise itself is located somewhere. These locations, and the addresses that represent them become the “Where” aspect of the enterprise.

We have all heard the cliché that “time is money” or the old dictum “tempus fugit”. For better or worse we live in a world delimited by time. Time usually takes two forms, moments in time, that is “events”, and durations, how long something takes. This time bounding defines the “When” aspect of the enterprise. Since another cliché, “time is money” almost always proves to be true, the time aspect of an enterprise can have a profound effect of its ability to sustainably accomplish its mission.

The final aspect of the enterprise concerns motivation and is quite often the most difficult to measure and to recognize its effect on the performance of an enterprise. The motivation aspect addresses the question of why certain courses of action are chosen or should be chosen, why certain types of persons and organizations are important, why certain products should be more heavily invested in and what corrective actions need to be taken for others, why certain events are important, and why some locations are preferred over others. Motivational factors are typically measured by inference, based on our assumption that because certain motivators were in place when an action took place that the motivators influenced that action. To an extent accepting the effect of this influence is an issue of convention. Never the less, no one can argue against the real changes in behavior brought about by strategically placed incentives, both positive and negative. Nor can we overlook the motivation of measurement itself, as has been said “what gets measured gets done”, which makes it imperative to measure the right things.[iii] Motivators become the “Why” aspect of an enterprise, and they can vary from the altruistic to the purely financial.

Enterprise Architecture has become a lot more visible and has received a lot of coverage in the IT press over the past five to ten years. This is at least in part due to the U.S. government’s passage of the Clinger Cohen Act back in 1996, and also to a growing need for organizations in both the public and private sectors to link together two of the most predominant initiatives within their operations: the strategic direction of the business and the increasing investment in information technology. The idea is to align the technology investment with the strategic direction. While there are many different approaches to doing this they almost all fall under the heading of Enterprise Architecture in one way or another. This gradual recognition of Enterprise Architecture has led to an increase in methods to implement it. Some of these ideas go way back to the 1980’s and others are purely 21st century phenomena.

Many of the approaches to Enterprise Architecture require tremendous dedication and effort to understand and implement. What I have attempted to show in this brief article is that there is an approach that builds on what many people already know . It essentially ties together the strategy and business processes of the Business Architecture with the computer based applications and infrastructure of the Technical Architecture. This linkage, especially where business process objectives are directly and logically realized in computer applications forms the traceability needed to verify the entire end-to-end Enterprise Architecture, from the top of the value chain in vision and mission through to the most physical aspects of the value chain in the components of the software and hardware infrastructure required to automate its implementation.

 


[i] Data Model Patterns, A Metadata Map, David Hay, 2006.

[ii] With knowledge work continuing to become more and more critical to successful value creation for both individuals and organizations it seems fair to assume that the era of the “loyal” employee will continue to recede further into the past.

[iii] A topic for another article, and my apologies to the former CEO of GE often credited for this quote.