Topic 7 / Post 3 – Evaluating Emerging Technologies, Innovations & Trends / Innovating Enterprise Value Chains

April 24, 2016 / Dennis Holinka

Topic 7 – Evaluating Emerging Technologies, Innovations & Trends

This week's posts go over the Evaluating Emerging Technologies, Innovations & Trends, the various perspectives, and related reflections in the blog.

Post 3 – Innovating Enterprise Value Chains

The evaluation of emerging trends, technologies, and innovations have provided multiple insights into the respective ideas that will lead to creative disruption in the conventional enterprise value chains.  The three areas that have the greatest impact on the value chains today are related to Business Model Innovation, Service Digitalization, and Dynamic Business Process Management.  These trends in innovation have created new expectations in the way business structure themselves and in the activities they seek to provide in order to provide value.  The traditional value chains of Product, Marketing, Sales, Service, and Operations are giving way to organizational innovations and management innovations in order to provide for those trends.  The conventional business model can be easily represented using a GODS architecture model that shows value chain and value add flow of the enterprise.  That value chain can be furthered decomposed into value streams across the enterprise.  IBM research indicated that there are at least 18 distinct value streams in an enterprise depending on factoring which can then be broken down into value stages according to the Business Architecture Guild.  The Business Architecture Guild has demonstrated that there is a link between value stream stages and business processes and then links from business processes to IT services.  The point of the matter is that the new trends operate by the decomposition, restructuring, and reconfiguration of business processes, value stages, value streams, and the enterprise value chain. 

Figure:  Restructure Value Chain

(from: http://slideplayer.com/slide/6392963/)

The business model innovation is enabled by new technologies but even more so by the fact that business models are being innovated in ways that were previously impossible due to the lack of technologies.  For instance, the enablement of customer centricity, digital analytics, cloud, mobile, and social have provided an extended nexus of forces that allow business who were strictly consigned to their business models to dynamically reshape their business boundaries in order to quickly assimilate backward and forward supply chain integrations.  According to Gartner, "IT has been an accelerating force in creating new ways of doing and optimizing business activities. Social and mobile technologies are the latest forces to proliferate business model innovations.  Business models that previously applied in niche areas can now be applied to many different product and service types as new technologies completely change the economics."

Figure:  Governance Operational Development Support Architecture Value Chain

(from: http://www.bptrends.com/publicationfiles/FOUR%2012-07-10-ART-A%20Single%20Page%20Generic%20BA-Grigoriu.pdf)

The enterprise can be innovated using the business model canvas and the opportunity analysis canvas.  Previous business model innovations were not possible given the limited technologies to implement them.  However, the nexus of forces of mobile, social, digital analytics, and cloud have combined to provide an technology innovation underpinning to allow for the reassembling of business and opportunity models.  The ability to provide such reshaping is from those technologies which allow you to deconstruct, restructure, and reconfigure those businesses into new forms.  The new form now include the ability to provide Service Digitalization, a new innovation and trend to provide expanded product support beyond the base products and to connect related or orthogonal business services into the existing business offerings.  Those connections would not be complete if it were not for the ability to build upon other innovations such as customer centricity and predictive analytics to seamlessly weave value into a rich user experience.  According to Gartner, "The trend to provide computerized or 'digital' extensions to services has also become so important that, even in traditional manufacturing industries, the service element can sometimes become the more lucrative part of the total package to customers. By using the Internet as a delivery platform to provide remote tailored design, installation support, training, configuration advice, insurance, monitoring and analysis, peer customer networking or other service features, companies can add value or differentiate their offering."

Figure:  Supply Chain Ecosystem Organigraph

(from slide 5: http://www.slideshare.net/fullscreen/anandsubramaniam/supply-chain-risk-management/5)

The richness of the new user experience comes from the agility and flexibility that can be customized into the user interactions.  This possibility comes from the new innovation of dynamic business process management.  No longer are business process of all sizes - long and short running - too rigid to be redirected but rather, the process technology can now mimic human interception by building it as part of the technology itself.  The new changes in business process, business model, and service expansion would not be possible if there weren't addendum innovations in the People category besides Process and Technology.  It is here that organizational innovations that allow for dynamic workflows between employees and knowledge sharing as well as management innovations in reward systems that allow for autonomous interactions which make that happen.  According to Gartner, "... IT architectural components (service-oriented architecture [SOA], messaging, metadata process description, Internet connectivity, rule engines and simulation) have evolved to the point where processes can be continually, rather than periodically, reconfigured. In some cases, a process flow can even be modified midway through its execution. Valuable customer proposition breakthroughs are made possible via more-dynamic process flows, such as Delivery Intercept by UPS in the logistics industry. However, relatively few business leaders have yet grasped the enormous efficiency potential of this shift. It requires new ways of management thinking and organization design, as well as considerable technology investment."

Figure:  Purpose Driven Enterprise

(from: http://markjamnik.com/purpose-driven-business/)

 

In the end, the value of all innovations is that it is linked to the mission and vision of the enterprise and if it is a for profit entity, the profit / not for profit of the business will signal whether you are building an enterprise supported and rewarded by customers or donations will signal your worth as a charity.  The ability to use all of these innovations, align them to the enterprise architecture, and provide comprehensive integration that improves your value chain is done in order for the enterprise to thrive in the marketplace. In conclusion, the enterprise exists to serve the customer in things they want, in things they don't know they want yet, so that your business model will make enough profit, etc., after all is said and done, to allow you to continue to serve in an unforgiving and competitive market.
 

Topic 7 / Post 2 – Evaluating Emerging Technologies, Innovations & Trends / EA Innovation Cycle - Agile EA

April 24, 2016 / Dennis Holinka

Topic 7 – Evaluating Emerging Technologies, Innovations & Trends

This week's posts go over the Evaluating Emerging Technologies, Innovations & Trends, the various perspectives, and related reflections in the blog.

Post 2 – EA Innovation Cycle - Agile EA

The EA Innovation Cycle is the integration of innovation management back into the enterprise transformation process. In an earlier discussion review of the innovation cycle, I came to the conclusion that innovation separate from innovation would lead to sprawl.  The various firms which I have consulted for have been examples of technical debt accumulation and obsolescence hoarding.  The companies have accumulated so much technologies that the operational run rates of those old innovations have now become economic burdens to them.  Light on maintenance have run over 75 percent and in some cases have approach over 80 percent in some of the companies.  The question that should be asked is how can this happen in companies who are used to providing innovative solutions for their customer and have grown to the point as leaders in their respective industries.  The answer lies in management processes that are isolated and unsustainable without integration with co-processes to balance the good and externalities that those processes produce. 

Figure:  Obsolescence based Technical Debt Accumulation from Innovation

(from: http://shhetri.github.io/unit-testing-to-tackle-technical-debt/images/refusing-to-tackle-technical-debt.jpg)

 

The creation of every new innovation will have the unintended consequences of turning once innovative systems into deprecated technologies and applications.  In that sense, the creation of one new innovation is the destruction of an old innovation that is in need of technical renewal.  Any post innovation creation that doesn't handle the destructive removal or remediation of obsolete systems works to create technical debt similar to allowing errors in code or architectural issues.  These bundled systems of code will begin to accrue interest just like poorly developed application.  First, it is the transition to the obsolete state followed by technical debt accumulation.  Does that mean we should become Luddites and refuse any new technology innovation or emerging changes? No, but it does mean we must purposely manage the transition of the deprecated systems to be on par with the state of the art.  In order to proceed that way, we must utilize the transformation processes that are available to transition current state to future state.  Fortunately for us, we have Enterprise Architecture processes which can integrate to coordinate the innovation management process with the EA transformation process for obsolete systems and get them to real time modern currency. 

 

Figure:  Innovation to EA integration - Agile EA

(from:https://cdn2.hubspot.net/hubfs/183807/eBook,_Agile_Enterprise_Archtiecture_and_Innovation_Management/Enterprise-Architecture-and-Innovation-Management-eBook.pdf?t=1461341169725)



As illustrated, the coordination point between "Ideas and Initiatives" and the EA process is linked by way of campaigns emanating from strategy and vision leading to innovations from the business context and trends to the emerging technology ideas innovations to EA.  The point in transition will require a portfolio assessment of the impact that the innovations can have on the entire enterprise architecture current state as the proofed innovations will represent the future state architecture and the implied need to remediate the deprecated and obsolete portfolio current state.

 Figure:  Innovation Impact Assessment to EA Portfolio for Applications and Technologies

(from:https://cdn2.hubspot.net/hubfs/183807/eBook,_Agile_Enterprise_Archtiecture_and_Innovation_Management/Enterprise-Architecture-and-Innovation-Management-eBook.pdf?t=1461341169725)

 

The result of the assessment connection will allow for a more comprehensive and holistic analysis for the removal of technical debt by way of obsolescence.  The innovation process can be integrated not only by way of process connection but can be made comprehensive by including it as part of an EA meta model for Agile EA so that modeling can be performed and tracked across the process as artifacts in architecture.  The combination of the campaigns and ideas are related to the EA impacts and the portfolio that they contain so that no innovation is disconnected with the mission, goals, objectives, strategies, and initiatives that the enterprise must have by way of traceability and relatability to the firm's value proposition.

 

 Figure:  Innovation - Agile EA meta model

(from:https://cdn2.hubspot.net/hubfs/183807/eBook,_Agile_Enterprise_Archtiecture_and_Innovation_Management/Enterprise-Architecture-and-Innovation-Management-eBook.pdf?t=1461341169725)

 



Topic 7 / Post 1 – Evaluating Emerging Technologies, Innovations & Trends / Intrapreneurial Innovation Process

April 24, 2016 / Dennis Holinka

Topic 7 – Evaluating Emerging Technologies, Innovations & Trends

This week's posts go over the Evaluating Emerging Technologies, Innovations & Trends, the various perspectives, and related reflections in the blog.

Post 1 – Intrapreneurial Innovation Process

 The Innovation and Emerging Technologies and Trends process has been pursued during various points over the decades by many enterprises.  Many technologists have come to accept the disruptive nature of emerging technologies and their ability to be game changers for the companies that use them and the development teams that have to implement them.  The disruptive nature of innovations are that they bring about creative destruction as described by the economist Joseph Schumpeter in the 19th century.  That is, that the new makes way by destroying and improving on the old.  Such was the case of the car displacing horses and horse related business include state of the art technologies of the time.  So it is with emerging technologies whose ideas can be properly integrated to produce new value in an enterprise.  However, we must always remember the potential for the destructive acts that the new technology brings to the process.  I will discuss in another post how the innovation process can be tempered when combined with EA.  For now, we must analyze how to best assess emerging technologies including innovations whether in technology, organization, or management in a structured process.

Figure:  Creative Destruction Illustrated in IT

(from: https://media.licdn.com/mpr/mpr/p/2/005/0b4/2b6/1881547.png)

In the more than ten years in Enterprise Architecture, I have seen multiple failed attempts at evaluating emerging innovations that have burned through scarce company capital.  Many of the approaches were unstructured and described as just in time or agile.  But we must remember that in an attempt to be agile we don't make the enterprise FRAGILE in competitiveness.  Low maturity in many of the companies I have consulted for have been mostly unstructured and disconnected from the business.  As a recent example, I remember when one of the companies invested in an innovation process that was evaluating Google glass and another that was looking at drones prior to the licensing of such activities by the Federal Aviation Administration (FAA).  Yes, it would be great to have a way to evaluate Catastrophic Damages from Hurricanes and assess losses but was that the priority for the business.  Were there no more tangible revenue increasing or expense reducing opportunity that would materialize within the next 6 to 12 months?  The issues there appeared to be one where the image of being futuristic and ahead of the curve was counted more than the ability to be profitable or use the innovation as a business profit enabler.  The innovation will require that it displace the status quo at an improved economies of scale and return in investment by way of expense reduction and/or revenue improvement.

Figure:  Creative Destruction in Telephone Industry Example

(from: http://cdn.ttgtmedia.com/rms/onlineImages/mi_cio_edition_1013_page5_graphic1.png)

Several approaches to innovation and evaluation of emerging technologies have allowed for a highly active and furious rush to market with ideas culminating from multiple ideation access points in an enterprise.   An intrapreneurial innovation process should include the evaluation of ideas, the industrialization of those ideas to product, and the product deployment into useful sales or operation for full cost recovery.  When a company cannot provide a return for its innovations then the process or innovations it is producing should be held suspect and abandoned in favor of economic value that does.  As such, many innovations that have appeared to market, did not produce a profit that justified its creation.  As an example, financial instrument innovations, led to the what Warren Buffet called financial weapons of mass destruction and there was no creative aspect to them except to those believed them to be useful in specific contexts.  This points out that we must be careful to properly position innovations for their useful purposes and right fit for which they are being developed.

Figure:  Creative Destruction Innovations Must Create Value

(from: http://talesoftheenterprise.com/wp-content/uploads/2013/03/creative_destruction_sjpg1441-300x212.jpg)

 

Therefore, the definition of a generic process to structure innovation and the evaluation of emerging technologies becomes crucial to the contribution of value.  The process must incorporate several value stages in the value stream.  The process begins with the collection points of ideas from the business, external markets, trends, partners/supplier, and internal employees.  The ideas transition from collection to a discovery phase to determine what aspects of the ideas are worthy of pursuit by way of opportunities, surveys, and environment analysis.  Next, the innovation or emerging technology is evaluated against the full list of idea discoveries and place into a pipeline for prioritization based on risk and return.  The prioritized innovations are funded as projects in experiments from inception business case, architecture, design, and then implementation proof of concept.  The phases of progression of ideas to discovery to quality to experiment make up the proofing component of the process.  The next component of the process progresses into delivery with the phases of industrialization and rollout.  The industrialization is the moving of the business case and proof of concept to implementation and scale in order to make the implementation materialize.  The rollout and subsequent operational monitoring / tracking is realize benefits for resources expended and benefits expected from the innovation / emerging technologies.  The process completes but is not necessarily sufficient by itself without integration with EA which I will discuss in my next blog post.

Figure:  Generic Intrapreneurial Innovation Process

(adapted from ACME, Inc.)

 

Topic 6 / Post 3 – Emerging Business Architecture / Future of Business Architecture - Jobs Creation

April 3, 2016 / Dennis Holinka

Topic 6 – Emerging Business Architecture

This week's posts go over the Emerging Business Architecture, the various perspectives, and related reflections in the blog.

Post 3 – Future of Business Architecture - Jobs Creation

         The future of business architecture is highly tied to the purpose and mission of the discipline of enterprise architecture.  That is, it is tied to the purpose of developing a viable and sustainable enterprise such that it provides for wealth creation and valuable services for customers in society.  Enterprises and businesses must in principle follow their societal mission of wealth creation in pursuit of human flourishing for society.  The last decade has been a testament to the loss of jobs and financial crisis that have ruined families, wealth, assets, and the American Dream for many Americans.  If we as a country and even greater, as a global society want to flourish, it will require that we create these engines of economic wealth creation known as Enterprises.  Paraphrasing John Zachman of the Zachman Framework (e.g. ZIFA), the twentieth century and industrial age was about creating products and services, the twenty first century and Information Age is about the creation and design of Enterprises - they create products and services in their non visible architectures.
         In that same frame of thought, the future of business architecture must build upon the ashes of financial recessions and great foundations left by wonderful thought leaders.  The future of business architecture must be able to incorporate the extended environment in a dynamic manner to properly model and simulate transformations to the enterprise with an eye on the outcome being that enterprise is profitable.  I have had my share of personal injuries due to hyper-competitive work environments and failed business models that lead to large layoffs and uncertainties for me and my family.  The future of business architecture must be built using a robust framework that can use modeling to predict and prescribe enterprise transformations so that there is a mentality of abundance through the enterprise value creation.  In other words, the business architecture must be successful enough to provide job security and increasing wealth prosperity for all dedicated participants in the firm.
         The future of the enterprise will be tied to understanding the opportunities available to the business under transformation in order constantly update its firm and remain competitive with a sustainable advantage.  This will require a continuous and ongoing process of surveilling the outer environment, defining the business contexts and the formulation of excellent competitive advantage strategies for the firm.  The next iteration of enterprise business architecture will also have to include a study in the social aspects of the firm and there must be predictive and consistent models for transforming an enterprise that is ultimately run by humans even though they may be highly assisted by computers and information systems.  The future of business and therefore business architecture must include an opportunity for employees to become owners of the means of production even more than the providers of capital to those firms.  It should include the ability for a firm to provide security, wealth, and a future whose methods rest upon the expertise of business and enterprise architects to develop the models that inform the organization on how to achieve profitable outcomes over the sustained long term.
         In order to achieve this, we will have to expand upon the current metamodel such as EBMM and begin to incoroporate many of the needed concepts and information models required to manage the firm methodically and precisely.  It will require an explosively robust ontology of relationships between many terms and concepts that are founded upon sound theories of profitable firms and their business strategies.   The future begins with defining the future state and documenting the current state and driving a roadmap to get there.  Depicted is the generic EBMM model that will require considerable expansion.

Figure:  EBMM Conceptual Model - Starting Point for Expansion

https://i0.wp.com/motivationmodel.com/wp/wp-content/uploads/2009/04/HighLevelView1.png

         In addition, the business architecture domain will require a considerable ontological expansion of its theoretical domain to include socio technical aspects of enterprises, particularly, the motivation and engagement of human resources in order for people to be valued as assets that improve the value outcome for an enterprise.  Even if we were able to automate the creation of all things in society but didn't that have a system, to direct the benefits on behalf of people, we will have lost the purpose for which these enterprises exist.  Stated differently, enterprises exist to service people and for their benefit.  Any enterprise architecture that doesn't improve the lot of employees and customers will have serious defective limitations on its internal strategies as they will be found to be in constant conflict with people who run those enterprises.
         The ontology development of the firm will require social science aspects be weaved into the metamodel so that the relationships and principles of sustainable human resourcing will enable the enterprise to achieve success.  The future of business architecture will hinge upon having the right information architecture about the business laws that apply uniformly for success business where it concerns the people, process, and systems that are employed by the organization under concern.  Today, the models of the firm are limited in a form of capability modeling transformation approach as depicted.

Figure:  EnterpriseArchitects.com Capability Modeling Approach

http://www.adoit-community.com/wp-content/uploads/ADOit-Info-Day-EA-Pres-v1.1.0.pdf

         The future will require an ontology be based more on a dynamic enterprise socio technical system, multi stakeholder analysis of the extended enterprise such as the one adapted in the depiction.  The model shows that there is a comprehensive set of influences that allow the business architecture to survive from the corporate structure, its internal pursuits, to the external influences such as culture flowing from society from whence the employees are resourced.

Figure:  Adapted Enterprise Dynamic Ecosystem Influences

https://worldbusinessincubation.wordpress.com/2014/06/04/generic-business-incubation-model-systems-engineering-view-part-4/

In conclusion, the future will require that we have a greater understanding on the levers and direct/indirect drivers of business success and that the enterprise architecture is socially sustainable in addition to the sustainability of its profit model.  Only then will we be able to purge the financial crisis of the future and create jobs that are worthy of human dignity and talent as we follow our existence with the right to life, liberty, and the pursuit of happiness and the Truth.

Topic 6 / Post 2 – Emerging Business Architecture / Enterprise Solution Architecture and Artifacts

April 3, 2016 / Dennis Holinka

Topic 6 – Emerging Business Architecture

This week's posts go over the Emerging Business Architecture, the various perspectives, and related reflections in the blog.

Post 2 – Enterprise Solution Architecture and Artifacts

          In the effort of realizing the enterprise architecture of a firm, we must eventually use the enterprise architecture future state to develop roadmaps that lead us to creating solution architectures.  The solution architectures are more than one time created artifacts for a particular pain point solution.  That is, we must develop or rather assemble solutions from a fixed set of inventory of items or work to develop a set of inventory of items for the creation of solutions for the enterprise.  The process of enabling this effort must proceed from a methodology that leads to the development of such an inventory of items that can be made available for reuse.  As recommended by the Gartner metholdology, we should embark on a process of developing sets of solution portfolios which can be categorized and organized by technical patterns and services.  
          We must develop the Solution Architecture to align with the Enterprise Architecture Future State in alignment with the business context as outlined by Gartner's process.  The process will include determining high level options for the solution, analyze the benefits and disadvantages of each option and chosing, determine if there are any existing solutions or reusable solution assets either in the form of a reference architecture or reusable architecture instead of buying and/or building new solutions or components.  Next, determine any relevant design patterns and technology standards apply while making sure that the current solution is architected and leveraged for future potential reuse.  Provide documentation and explain architecture trade off decisions such as identifying any key issues, risks or challenges and propose risk mitigation approaches or trade off options analysis.  The solution architecture is the intersection of the business, information, and technology architecture as specified by the Gartner process and provided here as a model.

Figure:  Generic TOGAF and Gartner Solution Architecture framework

Adapted from http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html#tagfcjh_75 and https://psu.instructure.com/courses/1772177/files/77042619/download?wrap=1

It is important that a number of artifacts be developed that provide the articulated solution architecture models that are assembled from the distinct list of relevant models as they relate to the distinct solution categories in the enterprise.  It is important that a categorized inventory of models be cataloged and indexed for reuse using the Technology Reference Model (TRM) as specified by the TOGAF framework.

Figure:  TOGAF TRM for Cataloging Reusable Solutions

http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap43.html

There is a required set of artifacts that are needed to be developed from the the various TRM categories or from the design pattern and service catalog.  This requires that a solution be assembled using an approach of using the available inventory or creating inventory in the process of solving the transformation at hand.  You can provide the following artifacts as listed in the depicted set as a starter for the models required to provide a comprehensive solution.

Figure:  Generic Gartner and TOGAF Solution Architecture Example Deliverables

Adapted from http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html and https://psu.instructure.com/courses/1772177/files/77042619/download?wrap=1

Last, we must assure that the artifacts provided are assured in a review process to guarantee that quality architectures are being developed and that organizational policies and principles are followed.  Therefore, we must ensure that all solutions are aligned appropriately to the enterprise strategic direction, standards, and enterprise transformation roadmaps.  Review that all solution architectures have quality design, are robust, and meet all functional and non-functional technology requirements.  We must review the solution and apply a consistent set of rules, guidelines, and decisions across all solution architectures developed.  The review also provides the appropriate forum to discuss and resolve key design challenges that may require new designs, reference architectures, standards, technologies, and other non-functional requirements that impact the enterprise.  The reviews must incorporate solution architecture models to contain the completeness and accuracy of the systems to be built by the development teams. Solutions must reuse enterprise blueprint solutions and meet horizontal business needs across the Enterprise according to stakeholder consensus.

Topic 6 / Post 1 – Emerging Business Architecture / Business Capability Modeling and Business Architecture

April 3, 2016 / Dennis Holinka

Topic 6 – Emerging Business Architecture

This week's posts go over the Emerging Business Architecture, the various perspectives, and related reflections in the blog.

Post 1 – Business Capability Modeling and Business Architecture

         There is nothing as confounding as the modeling of business architecture as is found in the discipline of Enterprise Architecture.  The discipline of Business Architecture is focused on architecting the business in such a way to provide for its transformation to a future state from its current state.  However, the questions that are raised are numerous such as what modeling depictions should we use and what are the models that we should produce.  Moreover, what is the value in the models and what is the value of all of that effort are the questions being examined by business and enterprise architects in the industry.  Recently, I have engaged in a discussion with a expert in business architecture from the business guild after having attained a yearly membership.  The discussion was related to the much needed information regarding the link of understanding the foundational terms in business architecture that keep emerging in the industry and academic literature.  That is, what is business capability and how is it different from business process, business function, business value chains, and business value streams.  The confusion emerges because there are many terms bandied about but these terms need to be precise in order to properly understand their elements and any relationships these terms have to each other.  Another set of questions around business capability modeling is how is it done and how do you know if you have properly factored them.  What is the relationship between them and how do we know if we have gone to far and too deep in the process of business capability modeling.  
         The answer begins in understanding the means to achieve ends.  That is, why are we doing any of this and what is the purpose of knowing everything we want to model and understanding the lineage of the relationships across the business capabilities.  It has been documented that business capabilities language is the lingo of executives in encapsulating many of the resources that are required in order for an enterprise to achieve an end in its future state or in a specific strategy outlined for the company.  It is here that a enterprise capability is a composite of what it does which is described by its function (i.e. what),  which resources are required in people, technology, and process of how it is done to achieve an outcome.  My reflection over this field is that there needs to be a precise ontology and metamodel for the field of enterprise architecture that precisely incorporates the meanings and depictions of these terms for the sake of de-conflating the ambiguity in the field.  Confusion exists with architects and IT professionals alike who proceed to model these imprecise and ambiguous constructs which works to dismantle the methodology of deconstructing and re-synthesizing the newly abstracted future state enterprise.
         The literature for enterprise architecture begins by consulting five sources which I have found to help me to construct a more precise mental model for the creation of business architecture models and extracting the value that is inherent in the methodology of modeling those abstractions.  Gartner definitely provides the best explanation of starting with the business context and creating the Customer Requirements Vision (CRV) with its traceability from goals, strategies, initiatives, and transformations for the business to IT systems and runtimes.  What I have found illuminating is that there is an articulation of a metamodel that says each of those components are related in the form of means to achieve ends (e.g. future state).  The business architecture models from there, generally speaking are models that would bring clarity to the transformations that are required and necessary to transform the enterprise.  For instance, there are models that would require us to understand as well as to inform us on the importance of understanding why the business process models are constructed the way they are.  In other words, some missing models of what we need are what are the business model canvas of our business profit model and what are the product models that make up those business models.  It is on those models, that we derive process contexts as to why and how our business needs to change besides stating generally that our business operations needs certain aspects and features.   The business profit model provides us with the insight on how the current processes either achieve or don't achieve the profit model being pursued as depicted.

Figure: Business profit models from business context

http://www.adoit-community.com/wp-content/uploads/ADOit-Info-Day-EA-Pres-v1.1.0.pdf

         Here we can benefit from the Business Guild and Gartner's methodology of decomposing the enterprise into value chains and value streams.  It was once documented by IBM research that there were 18 distinct value streams across the enterprise.  Each of those value streams would decompose into a value stage and the value stage would have a decomposition into business process.  It is here that we need to make a major distinction between business function and business process including cross boundary business processes.  Moreover, as architects we should be working from reference models for an enterprise and have a few places in which we can look to start the work without starting from scratch.  The use of business function, business process, and business capability models are available in the industry with limited explanation between each of them from ACORD for functional/capability model that is focused on only the customer facing portions of an enterprise.  APQC is focused on process and doesn't provide a complete view of the functional breakdown of an enterprise to the point that process can be understood comprehensively.   Gartner provides a breakdown of how these items are related to each other in the following depiction.  In addition, the functional relationship between a business function and business process is provided.

Figure: Gartner business architecture model relationships

https://psu.instructure.com/courses/1772177/files/77042588/download?wrap=1

Figure: Traditional functional hierarchy of a firm in relation to business process

http://www.processorientation.com/?p=82

         The best places to understand the relationship between function, business function, business process, and business capability is from EnterpriseArchitects.com, TOGAF 9.1, and EBMM. There are three models that provide a clear understanding of the simplicity and complexity of the relationship of the models being reviewed.  At EnterpriseArchitects.com, a business capability realizes a capability in that a capability is abstract without the ability to perform the logical function.  Moreover,they provide functional processes and well as cross functional processes to understand what makes up a capability. 
                                              

Figure: Functions realize capability

http://enterprisearchitects.com/business-function-does-it-have-a-place-in-business-architecture/

Figure: A conceptual framework for thinking about capabilities, services, business functions and processes
http://enterprisearchitects.com/business-function-does-it-have-a-place-in-business-architecture/

 In TOGAF, there is a recursive relationship with function and process which is depicted in the model provided by The Open Group which explains why there is much confusion in modeling these concepts.  It is explained that "function describes units of business capability at all levels of granularity such that the term 'function' is used to describe a unit of business capability at all levels of granularity, encapsulating terms such as value chain, process area, capability, business function, etc. Any bounded unit of business function should be described as a function." as depicted.

Figure: TOFAF framework for thinking about business functions and processes

http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap34.html

Lastly, it is important that a metamodel depict the relationship across the scope of the enterprise and all of the lineage that may be required to depict the details of the enterprise business architecture model components in order to plan the target state transformations.  It is here, I recommend the use of of the EBMM for the big picture view of the enterprise from business context to business profit models, product models, service models., business value chain, business value streams, business value stages to business processes, to IT and systems and runtime models.

Figure: Enterprise Business Motivation Model (EBMM) - Primary Viewpoint v4.2

http://i.msdn.microsoft.com/aa699429.art2fig10(en-us,MSDN.10).jpg

Topic 5 / Post 3 – Security Architecture Layer / Software Defined Security - Global Security Compliance Rules

March 20, 2016 / Dennis Holinka

Topic 5 – Security Architecture Layer

This week's posts go over the Security Architecture Layer, the various perspectives, and related reflections in the blog.

Post 3 – Software Defined Security - Global Security Compliance Rules Consolidation

The future of software defined security will be difficult unless there is a metadata driven architecture to provide a central approach to the way security architecture rules and controls are implemented. Most global enterprise are constantly chasing the deluge of controls across multiple privacy, security, legal, regulatory, and compliance taxonomies.  Among the taxonomies that abound are the following frameworks that contribute to creation or redundant mapping of a control:  AICPA 2014 Trust Services Criteria, Canada PIPEDA (Personal Information Protection Electronic Documents Act), COBIT 5.0, COPPA (Children’s Online Privacy Protection Act), CSA Enterprise Architecture, ENISA (European Network Information and Security Agency) Information Assurance Framework, European Union Data Protection Directive 95/36/EC, FERPA (Family Education and Rights Privacy Act), HIPAA/HITECH act and the Omnibus Rule, ISO/IEC 27001:2013, ITAR (International Traffic in Arms Regulation), Mexico - Federal Law on Protection of Personal Data Held by Private Parties, NIST SP800-53 Rev 3 Appendix J, NZISM (New Zealand Information Security Manual), ODCA (Open Data Center Alliance) Usage Model PAAS Interoperability Rev. 2.0, and PCI DSS v3.

In order for software defined security to inter-operate globally and meet programmatic objective and provide adaptability, a central information repository, similar to the one described in the Security Information Requirement for the Security Vision Requirements document described by Gartner.  This central repository should steward the cross mappings of the various global frameworks to simplify the number of controls and implied security architecture designs so that may be programatically applied to IT solutions for the business enterprise.  An example of an organization that provides such cross mappings is the Cloud Security Alliance whose mission it is to standardize on the security controls across domains and frameworks.  The controls matrix provided by the organization (CCM) assist customers in assessing the overall security risk of a provider with its intention of standardizing cloud providers.  According to the Alliance organization, CCM "provides a controls framework in 16 domains that are cross-walked to other industry-accepted security standards, regulations, and controls frameworks to reduce audit complexity, normalize security expectations, cloud taxonomy and terminology, and security measures implemented in the cloud":

 Figure: CSA - CCM version 3.0.1

https://downloads.cloudsecurityalliance.org/assets/research/cloud-controls-matrix/CSA_CCM_v.3.0.1-01-21-16.xlsx

According to Gartner, Phase 3 is "longer term, expect further transformation of information security to become software-defined itself.  The shift to SDx has the potential to generate organizational disruption" by requiring teams from server, network, storage, and information security integrate into a platform team.  The software defined anything SDx including security will require the standardization of controls and an API based approach similar to Open Stack for Security to emerge to provide the facade for provider specific implementations of security.  For example there are emerging SDN security controllers that can control the flow of open flow traffic defined by SDN.  This is achieved by separating the management, control, and data planes for security as well as network so that each can be controlled.  There are scripting languages such as FRESCO and controllers/kernels such as FORT/NOX that provide the ability to provide dynamic security to the network flows.  Similarly, SOA Gateways can be used to provide similar security features when combined with a programmatic management, control, and data plane provider. 

 Figure: Software Defined Network Security Application - Example

https://www.youtube.com/watch?v=H9NuhWbxbko

As you can see from the figure that the SDN Controller can manage the security of the software defined network that was topologically assembled.  A similar approach can be used if SDx is used at the process and application component layers as it is used here in the technology layer for network, server, storage, and information repositories (e.g. Data-stores).  The approach of using APIs that can reconfigure configurations/objects and manage intercepts for entry or exit functions for the application and technology layers will be required to provide the SDx Phase 3 integration for security across the IT stack.

Topic 5 / Post 2 – Security Architecture Layer / Application Security Architecture and Applied Design

March 20, 2016 / Dennis Holinka

Topic 5 – Security Architecture Layer

This week's posts go over the Security Architecture Layer, the various perspectives, and related reflections in the blog.

Post 2 – Application Security Architecture and Applied Design

Enterprise Architecture and quite similarly, Security Architecture is riddled with much confusion and ambiguity in how to make their implementations tangible.  If you ask an enterprise architect what consumables he or she will produce, you will fortunate to receive a list of artifacts as described by Gartner in the EA Charter document.  Similarly, Security Architecture has experienced a similar problem in that it is the experience of IT professionals that security architecture has emerged as a checkbox / compliance / controls based set of exercises and has limited if little visual modeling artifacts to produce that would be the visual depiction of the abstractions that are required for the creation of an architecture design.  It is here that there are a number of needed frameworks to provide an Enterprise Architect and even more so, a Solution Architect with a modeling discipline and set of techniques to produce artifacts from.  

Fortunately, the approach I have researched and provide here as a recommendation is the use of the IBM Security Framework and Security Blueprint Methodology coupled with a practical approach of enhancing existing Solution Architecture artifacts with security architecture designs.   The IBM approach formed its framework by decomposing the various sub-components of the Security Framework into parts that a solution architect will have to provide a visual modeling artifact for.  The practical approach of modeling each of these specific areas of control objectives which we can consolidate using a global controls list like CCM from the Cloud Security Alliance.  However, we should align each of the controls into the larger framework provided by the IBM Security Framework:

Figure: Enterprise Security Framework - IBM

http://www.redbooks.ibm.com/redpapers/pdfs/redp4528.pdf

The overall framework breaks up into various parts policy management planes and then into subcomponents of the policy domains for the security architecture coverage.  The policy governance and manaagement portions are the Command and Control Management, Security Policy Management, and Risk and Compliance Assessment.  The policy sub domains are Identity, Access and Entitlement Management, Data and Information Protection Management, Software, System and Service Assurance, Threat and Vulnerability Management, IT Service Management, and Physical Asset Management.  Each policy domain is broken into further sub-components along with Security Services Infrastructure components required to be addressed as part of the blueprinting of the solutions.  The solution approach can be enhanced modeling using Archimate and its Extended Motivation Model which maps the controls to the multi layer EA model diagram to document the various components of the framework and blueprint the solution.  

Figure: Archimate Extended Motivation Model - Mastering Archimate (The Open Group)

http://masteringarchimate.com/2012/04/13/modeling-risks-and-security-and-more/

By documenting each part of the framework using the Risk approach using the Archimate language, the solution artifacts in addition to those documented as part of the TOGAF Security Architecture ADM deliverables will provide a detailed design for implementing and understanding the security architecture designs.  As a matter of convenience I providing the list of subcomponents of the frameworks that will have to be modeled.  The best approach to modeling would be to walk down the security framework and align the various global standardized controls from CCM and place them within governance, policy oversight management, or policy domain sub component frameworks.  Then model the various controls as they apply to the SRV - Security Requirements Vision as detailed in the SSR - Security Solutions Requirement map to the various matrices and traceabilities to STR, SBR, SBP, STT, and SIRs in the SRV.  They are as follows and should use the above Archimate modeling technique to design the security architecture including more detailed models such as UML that will further decompose the Application Architecture layer in Archimate.

Figure: Enterprise Security and BluePrint Framework - IBM

http://www.redbooks.ibm.com/redpapers/pdfs/redp4528.pdf