Wednesday Jan 20, 2016

Solving the Polyglot Persistence Puzzle - Defining the Information Value Lifecycle

I believe an Information Architect’s primary purpose is to increase the value of the information assets belonging to an organization. Securing and making information available is no longer sufficient to grow the competitive capabilities of an organization. Information architects must get:

  • the right information
  • to the right person
  • at the right time
  • in the right format
  • so the best decisions can be made at all levels of the organization.

To assist Information Architects in understanding and defining a process to increase the value of information assets, I have created an Information Value Lifecycle map. This is the first step in understanding the characteristics of information on the way to building Polyglot Persistent Architectures.

Building an Information Value Lifecycle map is done in 7 steps.

Step 1 – Build the Information Value Lifecycle map layout.

Each organization has multiple levels of decision making. For each level of decision making, there are Information Usage patterns and the Information Structures needed to support the usages. The example below starts with the Transaction Owners, the staff that create, maintain and own the transactions required to run the business. At the highest level are the CEO and Board of Directors (BoD). Maps will differ to reflect each organization’s hierarchical process of decision making.

Step 2 – Define the Information Usage patterns and the Information Structures needed to support the Information Usage pattern.

Typically different levels of decision making require different levels of aggregation and summarization of information – from simple transaction reporting to cross line of business and industry aggregations, analytics and predictive analysis. Information architectures over the years have evolved well know sets of information structures (most commonly 3rd Normal Form, Star, Snowflake and Cube schemas) needed to support these Usage Patterns.

Step 3 – Define the processes needed to transform and aggregate information from transactions to the highest level of the decision making process.

Extract, transform and load (ETL) processes move information from one level of decision making to the next based on the information usage patterns. Mapping these ETL process at a high level ensures data linage is understood and information accuracy is guaranteed. Some applications provide capabilities that ‘jump’ the information past some levels to the highest levels of the decision making process. Oracle Hyperion is an example.

Step 4 – Record Master Data Management usage patterns

Understanding Master Data usage patterns gives insights into which types of information are most important to an organization. They also indicate the level of information management maturity – more usage of master data reflects an understanding of the value of master data and a willingness to invest to realize that value.

Step 5 – Identify Big Data usage patterns

Most organizations have begun the process of deploying and realizing the value of Big Data. Recording Big Data usage patterns shows the maturity of an organization in relationship to their ability to adopt and deploy new technologies.

Step 6 – Identify the ‘Gold Nuggets’ in Big Data

Identify where Big Data data mining and analytics has increased the quality and/or quantity of information inputted into the Information Value Lifecycle. These processes are commonly referred to as finding the ‘Gold Nuggets’ of information that were previously not known. It’s important to understand the value of the ‘Gold Nuggets’ in the decision making process of an organization to justify the level of effort and expense of deploying Big Data architectures.

Step 7 – Identify new Big Data information value opportunities

The low cost of some Big Data architectures has allowed organization to capture new sources of data that have lead to new ways of doing business. Many of these use cases include social media as a way of judging the success of marketing campaigns and new product lunches. Capturing these Big Data opportunities shows the agility and innovativeness of an organization.

In the next blog I will introduce the 16 Information Characteristics that make up the heart of the Information Characteristics Architecture Method.

Thursday Sep 13, 2012

BPM Process Accelerator Packs - Update


There are 3 BPM Process Accelerator Packs available now (Accelerator Packs Available ) as discssed in my earlier post:

There is a new and very useful white paper on BPM/Accelerator best practices at:

Thought I'd post that as the topic is getting more and more attention in various discussions I have been having.

Monday Sep 10, 2012

Current State EA: Focus on the Integration!!!

[Read More]

Friday Jun 22, 2012

Even EA's Have Bad Days - it's Time to Reset

I saw this article and thought I'd share it because, even we EA's have bad days and the 7 points listed are a great way for you to hit the "reset" button.

From Geoffrey James on INC.COM, here are 7 ways to change your view of things when, say, you are hitting a frustration point coordinating stakeholders to agree on an approach (never happens, right?)

Positive Thinking: 7 Easy Ways to Improve a Bad Day

To paraphrase:

  •          You can decide (in an instant) to change patterns of the past
  •          Believe in (or even visualize) good things happening, and they will
  •          Keep a healthy perspective on the work-life / life-life continuum (what things REALLY matter in the big scheme of things)        
  •          Focus on the good (the laws of positive-attraction apply)

Thursday May 31, 2012

The Application Architecture Domain

I have been spending a lot of time thinking about Application Architecture in the context of EA. More specifically, as an Enterprise Architect, what do I need to consider when looking at/defining/designing the Application Architecture Domain?

There are several definitions of Application Architecture. TOGAF says “The objective here [in Application Architecture] is to define the major kinds of application system necessary to process the data and support the business”. FEA says the Application Architecture “Defines the applications needed to manage the data and support the business functions”.

I agree with these definitions. They reflect what the Application Architecture domain does. However, they need to be decomposed to be practical.

I find it useful to define a set of views into the Application Architecture domain. These views reflect what an EA needs to consider when working with/in the Applications Architecture domain. These viewpoints are, at a high level:

Capability View: This view reflects how applications alignment with business capabilities. It is a super set of the following views when viewed in aggregate. By looking at the Application Architecture domain in terms of the business capabilities it supports, you get a good perspective on how those applications are directly supporting the business.

Technology View: The technology view reflects the underlying technology that makes up the applications. Based on the number of rationalization activities I have seen (more specifically application rationalization), the phrase “complexity equals cost” drives the importance of the technology view, especially when attempting to reduce that complexity through standardization type activities. Some of the technology components to be considered are:
  • Software: The application itself as well as the software the application relies on to function (web servers, application servers).
  • Infrastructure: The underlying hardware and network components required by the application and supporting application software.
  • Development: How the application is created and maintained. This encompasses development components that are part of the application itself (i.e. customizable functions), as well as bolt on development through web services, API’s, etc. The maintenance process itself also falls under this view.
  • Integration: The interfaces that the application provides for integration as well as the integrations to other applications and data sources the application requires to function.
  • Type: Reflects the kind of application (mash-up, 3 tiered, etc). (Note: functional type [CRM, HCM, etc.] are reflected under the capability view).

Organization View: Organizations are comprised of people and those people use applications to do their jobs. Trying to define the application architecture domain without taking the organization that will use/fund/change it into consideration is like trying to design a car without thinking about who will drive it (i.e. you may end up building a formula 1 car for a family of 5 that is really looking for a minivan). This view reflects the people aspect of the application. It includes:
  • Ownership: Who ‘owns’ the application? This will usually reflect primary funding and utilization but not always.
  • Funding: Who funds both the acquisition/creation as well as the on-going maintenance (funding to create/change/operate)?
  • Change: Who can/does request changes to the application and what process to the follow?
  • Utilization: Who uses the application, how often do they use it, and how do they use it?
  • Support: Which organization is responsible for the on-going support of the application?

Information View: Whether or not you subscribe to the view that “information drives the enterprise”, it is a fact that information is critical. The management, creation, and organization of that information are primary functions of enterprise applications. This view reflects how the applications are tied to information (or at a higher level – how the Application Architecture domain relates to the Information Architecture domain). It includes:
  • Access: The application is the mechanism by which end users access information. This could be through a primary application (i.e. CRM application), or through an information access type application (a BI application as an example).
  • Creation: Applications create data in order to provide information to end-users. (I.e. an application creates an order to be used by an end-user as part of the fulfillment process).
  • Consumption: Describes the data required by applications to function (i.e. a product id is required by a purchasing application to create an order.

Application Service View: Organizations today are striving to be more agile. As an EA, I need to provide an architecture that supports this agility. One of the primary ways to achieve the required agility in the application architecture domain is through the use of ‘services’ (think SOA, web services, etc.). Whether it is through building applications from the ground up utilizing services, service enabling an existing application, or buying applications that are already ‘service enabled’, compartmentalizing application functions for re-use helps enable flexibility in the use of those applications in support of the required business agility. The applications service view consists of:
  • Services: Here, I refer to the generic definition of a service “a set of related software functionalities that can be reused for different purposes, together with the policies that should control its usage”.
  • Functions: The activities within an application that are not available / applicable for re-use. This view is helpful when identifying duplication functions between applications that are not service enabled.

Delivery Model View: It is hard to talk about EA today without hearing the terms ‘cloud’ or shared services.  Organizations are looking at the ways their applications are delivered for several reasons, to reduce cost (both CAPEX and OPEX), to improve agility (time to market as an example), etc.  From an EA perspective, where/how an application is deployed has impacts on the overall enterprise architecture. From integration concerns to SLA requirements to security and compliance issues, the Enterprise Architect needs to factor in how applications are delivered when designing the Enterprise Architecture. This view reflects how applications are delivered to end-users. The delivery model view consists of different types of delivery mechanisms/deployment options for applications:
  • Traditional: Reflects non-cloud type delivery options. The most prevalent consists of an application running on dedicated hardware (usually specific to an environment) for a single consumer.
  • Private Cloud: The application runs on infrastructure provisioned for exclusive use by a single organization comprising multiple consumers.
  • Public Cloud: The application runs on infrastructure provisioned for open use by the general public.
  • Hybrid: The application is deployed on two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability.

While by no means comprehensive, I find that applying these views to the application domain gives a good understanding of what an EA needs to consider when effecting changes to the Application Architecture domain.

Finally, the application architecture domain is one of several architecture domains that an EA must consider when developing an overall Enterprise Architecture. The Oracle Enterprise Architecture Framework defines four Primary domains: Business Architecture, Application Architecture, Information Architecture, and Technology Architecture.

Oracle Enterprise Architecture Framework

Each domain links to the others either directly or indirectly at some point. Oracle links them at a high level as follows:

Business Capabilities and/or Business Processes (Business Architecture), links to the Applications that enable the capability/process (Applications Architecture – COTS, Custom), links to the Information Assets managed/maintained by the Applications (Information Architecture), links to the technology infrastructure upon which all this runs (Technology Architecture - integration, security, BI/DW, DB infrastructure, deployment model).

There are however, times when the EA needs to narrow focus to a particular domain for some period of time. These views help me to do just that.

Wednesday May 30, 2012

Who should ‘own’ the Enterprise Architecture?

I recently had a discussion around who should own an organization’s Enterprise Architecture. It was spawned by an article titled “Busting CIO Myths” in CIO magazine1 where the author interviewed Jeanne Ross, director of MIT's Center for Information Systems Research and co-author of books on enterprise architecture, governance and IT value.

In the article Jeanne states that companies need to acknowledge that "architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO". "If the CEO doesn't accept that role, there really can be no architecture."

The first question that came up when talking about ownership was whether you are talking about a person, role, or organization (there are pros and cons to each, but in general, I like to assign accountability to as few people as possible). After much thought and discussion, I came to the conclusion that we were answering the wrong question. Instead of talking about ownership we were talking about responsibility and accountability, and the answer varies depending on the particular role of the organization’s Enterprise Architecture and the activities of the enterprise architect(s).

Instead of looking at just who owns the architecture, think about what the person/role/organization should do. This is one possible scenario (thanks to Bob Covington):
  • The CEO should own the Enterprise Strategy which guides the business architecture.
  • The Business units should own the business processes and information which guide the business, application and information architectures.
  • The CIO should own the technology, IT Governance and the management of the application and information architectures/implementations.
  • The EA Governance Team owns the EA process.  If EA is done well, the governance team consists of both IT and the business.

While there are many more roles and responsibilities than listed here, it starts to provide a clearer understanding of ‘ownership’. Now back to Jeanne’s statement that the CEO should own the architecture. If you agree with the statement about what the architecture is (and I do agree), then ultimately the CEO does need to own it.

However, what we ended up with was not really ownership, but more statements around roles and responsibilities tied to aspects of the enterprise architecture. You can debate the semantics of ownership vs. responsibility and accountability, but in the end the important thing is to come to a clearer understanding that is easily communicated (and hopefully measured) around the question “Who owns the Enterprise Architecture”.

The next logical step . . . create a RACI matrix that details the findings . . . but that is a step that each organization needs to do on their own as it will vary based on current EA maturity, company culture, and a variety of other factors.

Who ‘owns’ the Enterprise Architecture in your organization?

1 CIO Magazine Article (Busting CIO Myths):

Thursday May 24, 2012

Complexity of Social Computing - Is it a Consideration for EA's?

In this "insane graphic" featured in an article in Business Insider's article titled "This INSANE Graphic Shows How Ludicrously Complicated Social Media Marketing Is Now" - opened my eyes to just how large the Social Computing Landscape really is (apparently Pintrest is not on this chart - imagine that?!?).  So, my quetion to folks out there is: does EA need to consider Social Computing in it's scope???  I have yet to see much discussion about thisbut think it NEEDS to be part of the puzzle.  I will think this through some more and do another post, but welcome ideas or feedback.


Social Media Map

To read more, the article is posted here:

Monday May 14, 2012

BPM Process Accelerator Packs




In as much as EA is about simplifying, streamlining and consolidating business processes, pre-built business processes can be very useful to lower the barriers to adoption of BPM-thinking.  That is to say, having the architecture and Business/IT allignment where the question asked is NOT "gosh, should we automate these new processes or reengineer some of these old manual-intensive processes?"   Hence, a shamless, but worthwhile plug for BPM Process Accelerators (or PA's for short) that were just recently announced.

The first two are out with others on their way:

Travel Request Management (TRM) User Guide UPK (PDF)
Document Routing & Approval (DRA) User Guide UPK (PDF)

Friday Aug 12, 2011

Focusing on Business Outcomes through Design

Whether we design paintings, buildings, or the functions of an enterprise, the element of design comes into play. The drivers for any design effort boil down to realizing business outcomes. Nothing more, nothing less. Two recent articles I found resonated with me on this topic and I thought I would share. 

Becoming a Design Leader

5 Questions to Help Recenter IT Design on the Business

Of course, your thoughts are most welcome!

Thursday Aug 04, 2011

Vanilla Apps - An EA's Friend

Packaged Applications (such as PSFT, eBiz, etc…) are the very operational heart and soul of most companies.  Whether it is human capital management, logistics, sales, or any number of other fundamental applications - they are most valuable when they are customized to fit YOUR business and integrate with YOUR systems.  The problem is that these customizations and integrations are most often done with built in (proprietary) tools or using things like PL SQL, batch files or other less-than-optimal (often proprietary) solutions.

Enterprise Architecture steps in at this point because the move from one major version to the next is a major undertaking for most companies; one that takes month (sometime as much as a year) to plan and implement.   When the applications have been customized to meet the business’s requirement, these very customizations make upgrading more complex.  One of the tasks of EA is to establish guiding principles which help shape decisions at every level of the architecture.  One key principle here is “Keep COTS Packages as Vanilla as Posible” – meaning do as little customization as possibly directly in the application itself.  The more vanilla the application is kept, the easier it is to upgrade.

It is a best architecture practice to place these customizations in the middleware layer where standards such as Java, Web services, XML, and the like mitigate the risks of using proprietary technology.  They also provide a more comprehensive and faster-development-lifecycle framework for integrating with the entire corporate IT ecosystem while greatly enhancing the possibilities for service/integration reuse.

So, with all that being said, a common question I get is “OK, where do we draw the line between using the built-in tools vs. using a middleware layer?”  This chart helps answer and provides delineation between the reasons to use one approach over the other.  Though not exhaustive, it should provide a framework for figuring out which customizations/integrations should go where.EOA-Ext


Thursday Jul 21, 2011

Passing TOGAF

Well, I passed the TOGAF Certification Exam.  Super happy.  Here is some advice that I passed on to someone who saw my previous post:

I recommend the class led by Architecting the Enterprise.  That will get you familiar with the materials but not ready to actually take the test.  At the end of the class they hand out a practice exam which is great for preparing.  The links I put on the blog are another set...

I recommend getting a study buddy who is preparing as well so you can quiz each other.  Read the book 8 times through, cover to cover.  Memorizing is only part of the battle, you have to really KNOW the materials.

Thursday Jul 14, 2011

TOGAF Certification

Well, I am one week away from going for my TOGAF certification.  For those who are also going for your certification and want some additional prep, I found two sets of additional questions for Part I and Part II (scenarios) of the test.  Check them out - good questions.

Tuesday May 24, 2011

Its always about the business (or mission)

So yesterday the follow-worthy @chrisonea lobs this question on Twitter:

Is there any circumstance under which IT should build a thing without a business purpose?

I emphatically answered, NO. Here's why.

Long ago when the last of the punch card machines were dispatched to the junkyards and the IT department was still called Data Processing, I was in college. Being an IT wannabe, I enrolled in my first COBOL course. Dr. Barone was my instructor and took us through all that verbose quasi-English that produced reports on green bar paper in the lab. Aside from COBOL, he taught us a bit about the relationship between the business and IT. IT, he contended, exists to serve the business and not the other way around. He was rather emphatic about it. We were not at liberty to code our hearts out like some painter with a canvas. We were to fulfill requirements. Nothing more. Nothing less. Sir, yes sir!

This idea has always stuck with me. Whether working in internal IT departments or producing software for external clients. Even in the latter case the software exists solely to achieve an objective for the client's business. It especially resonates well as I focus on enterprise architecture. 

If I were to rationalize an IT portfolio of applications or middleware, I still rationalize at the behest of the business. There is a realizable benefit that can be articulated in business terms. Reduced operating costs through simplification in this case. Every CFO and CEO understands that language. Even if I were to "build it and they will come" (speculation), there would still be some business outcome I'm seeking such as revenue generation.

Yes, ITs still about the business. Period.

Tuesday May 17, 2011

It's not the Journey, It's the Endpoints


[Read More]

Friday Sep 03, 2010

Thoughts on John Zachman

[Read More]

Art, Artifacts, and Best Practices for Enterprise Architects


« June 2016