Wednesday Mar 20, 2013

An Agile Enterprise Architecture (EA) Delivers Critical Business and Mission Agility

While working with a recent partner, the question came up; "What changes are made to the EA approach if agile methods are required, or otherwise heavily encouraged?" The initial answer at the time was "Not many – we already have an agile approach to EA embedded in our Oracle Enterprise Architecture Development Process (OADP), and our Oracle Enterprise Architecture Framework (OEAF) is independent of project management and project development approaches."

Our OADP has always been agile and therefore supportive of business and government agility – particularly in the current context of severely constrained budgeting cycles. We firmly believe in a "just enough, just in time" philosophy, with collaborative insight and contribution across teams and leadership, and delivery of EA artifacts or guidance tuned directly to prioritized results. This means strategic, useful and reusable guidance modeled and delivered in a manner that supports both longer-term initiatives and near-term objectives.

EA delivered as an agile approach, however, does require continual line-of-sight traceability back to the IT investment strategy – which in turn is aligned to the business strategy.  

In other words, a Sprint Iteration approach might be justified (i.e. using the "Scrum" strategy), from all relevant perspectives, to quickly establish a reusable process and metadata model for a common agency function – like "Document Routing and Approval" (DRA). The output might be required to inform a software solicitation (i.e. to explain the requirements).  The output might be to establish a reference model and basic governance (business rules) for identifying and improving process efficiencies around the agency where DRA is occurring.

The actual need for this EA artifact (or "Product", in Agile terms) may be driven from an unanticipated mandate or regulatory change, and therefore require rapid response.  The need may also be limited in scope to only a portion of the agency's business (i.e. those who actually know they need it).

So, an EA Sprint will work, and deliver what's needed quickly and effectively to the target audience.  The highest return on investment (ROI) in this exercise, however, only exists if actual Enterprise traceability and impact assessment occurs. In other words, an agile EA output with a strategic Enterprise outcome.

Note this is a common misunderstanding for Agile software development; Agile programming and project management may deliver useful, rapid and cost-effective "features" from a Backlog of priorities, but much of the supporting infrastructure, integrations and organizational change isn't delivered using Agile methods, but must evolve in a more strategic, methodic manner.  Preferably with EA guidance.

Here's what should happen.  The common DRA process, metamodel and business rules begin to shape, in a somewhat parochial "requirements-driven" context, heavily leveraging the impacted SMEs for a short period of time. As this occurs, the Enterprise Architect and stakeholders begin mapping and comparing the DRA process design (at appropriately coarse levels of abstraction) to any similar that may exist within the agency, or among agency partners or stakeholders.  This may require some additional outreach and communication.  The EA may find additional SMEs, risk factors, standards, COTS DRA solution accelerators, overlapping data management projects, etc. – essentially other activities or resources that can be used or might be impacted.

The Enterprise Architect is the Scrum Master!

Strategic oversight and influence is therefore brought to bear on the EA sprint, and by leveraging EA methods, the impacts to the rest of the organization plus any modifications to the focus EA artifact can be addressed – entirely within standard and expected IT Governance. The EA artifact development is a Sprint, but actually leverages our lifecycle methodology – from Business Context through Current and Future States, and then Roadmap (i.e. Transitional Architecture) and Governance.  The EA Sprint may actually kick off or modify a more holistic EA maintenance process.

We are therefore avoiding an "agile everything" philosophy, though we're delivering agile results.   We contribute over-arching guidance and process for both the DRA project and the organization as a whole, to make sure that all projects underway are still aligned to meet the needs of the business and IT investment constraints.

This is essentially what we believe in applying our EA process, over time or during more Agile response cycles; always raise and maintain focus on the business strategy and drivers to guide the investment of IT budget into those areas that affect the business most – or that are the most immediate priority, such as described above.

Thanks to Oracle Public Sector Enterprise Architect Ted McLaughlan for contributing to this article!

Friday Jan 11, 2013

Soft Skills, Leadership, and now Empathy

A recent post by @mikejwalker on a new Soft Skills course by Architecting the Enterprise rightly points out the importance of soft skills for the EA discipline. I think this is a great addition to the profession and shows formal recognition of the importance of soft skills in the industry.

The EA positions I've seen in companies are generally at a 1st or 2nd line management grades. Corporations seem to recognize at some level the need for a "higher stature" for the EA professional. The leadership skills take more cultivation than just updating the HR records, however. It takes a skillful balance of things perhaps even learned outside the scope of the office such as running a youth organization or planning other non-profit events. Corporations are wise to invest in leadership training - often only slated for management - for EA professionals. 

The EA profession is both strategic and change-oriented impacting people far more than the bucket of bolts on your data center floor. Changing behaviors in humans is at the core of the discipline. 

The above was written last week. This week @nickmalik rightly opines on the importance of empathy EAs. I only scanned this article (which deserves a good read by the fire with my favorite scotch). He's definitely onto something here...

Bottom line - soft skills are becoming increasingly important!!! So, fellow EA professional, what do you do to hone your soft skills? Who do you draw upon for leadership lessons?

Tuesday Jan 08, 2013

TOGAF Study Help - iPhone to the Rescue (perhaps)

TOGAF study help?!?! There is an app for that!

There is a app out on the iTunes store that seems like a possible study guide.  Have not used it and don't have a review of it yet, but thought it is intersting enough to point out.

p.s. Happy New Year Everyone!


Friday Jan 04, 2013

RACI Matrices, EA Charters, and Surgical Suites

In another moment of (over) thinking enterprise architecture, I was comparing the surgical suite to a project team. I'll define a team as a committee, or other ad-hoc group of individuals engaged in a particular task. While the surgical team has many members, they all play a specific role. And some, such as medical students, may be spectators viewing from above. In the surgical suite, folks know their roles. Students in the gallery know they are to take notes and not scrub in. Those perform procedures are not scribbling in their notebooks either. Everyone knows their part - before going into the surgery.

A common tool used within organizations to delineate roles and responsibilities is the RACI matrix. It simply describes the subject area along with levels of responsibility for the particular subject mapped to an organization unit, committee, or individual. While individuals may agree or disagree with the contents of the RACI matrix, at least its explicit and people can collaborate around it.

Like RACI matrices,  EA charters provide a level of clarity for EA programs in terms of the services they provide and what they don't provide. Composing a RACI matrix helps identify the various roles interacting with an EA program and who weighs in at what level for a particular concern. 

For your EA program, do you have a formal charter? Does it include a RACI matrix? How do you delineate responsibilities in a centralized or federated EA environment? 


Tuesday Dec 04, 2012

Basic is Best

Fellow foodies will recognize the recent movement towards "farm-to-table" restaurants. These venues attempt to simplify their menus and source ingredients as close to the source as possible. I had the opportunity to dine at such a restaurant the other evening. I was gushing about the appetizer to my server when she described the preparation for the item and then punctuated her comments with "basic is best". I reminded my fellow enterprise architect diners there was an architecture lesson in that statement. They rolled their eyes and chuckled. But they also knew I was right.

I'm reminded of Frederick Brooks' book The Mythical Man Month and his latest The Design of Design. The former must read book talks about complexity. But he refrains from damning all complexity. The world we live in and enterprises we strive to transform with enterprise architecture are complicated organisms, much like the human body. But sometimes a simple solution is the best approach. Fewer applications (think: portfolio rationalization). Fewer components. Fewer lines of code. Whatever level of abstraction you are working at, less is more.

I'm reminded of the enterprise architecture principle "Control Technical Diversity". At one firm I created pithy catch phrases for each principles. I named this one "Less is More". But perhaps another variation is what my server said the other night, "Basic is Best".

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:

Thursday May 17, 2012

Mobileize Your Business Process Applications

Mobileize Your BPM Applications

Recently, there has been a lot more talk about mobilizing corporate applications.  One of the customers that I work with wanted to know how they can mobilize their BPM applications.  There are a couple ways to do this.  Here are two different approaches (using ADF Mobile and/or Actionable Emails):

1. ADF Mobile:
b. (Datasheet)
c. (Documentation)

2. Actionable Emails:

 Figured that might help some people understand how you can mobilize your work force.

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)

Wednesday Feb 29, 2012

Cloud and IT Organizational Change

Does Cloud require the IT organization structure to change?  Or, is an appropriate IT Service Management framework all we need?  

[Read More]

How Strategic is IT? - Assessing Strategic Value

Why do we care?  Understanding the role IT plays in the business will be important in establishing proper scope, obtaining support for initiatives and delivering the greatest value to the organization. 

Recently I was working on strategies for Data Center Transformation.  The challenge was a scope focused on the technology domain during the Architecture Vision Phase.  How do we create alignment to the broader business architecture, when the drivers and KPIs tend to be tied almost exclusively to IT operating and capital expenses, or an idea of supporting business agility?

I was concerned that the technology architecture strategy that I was defining was too vague and treated IT as if it was applied monolithically - Standardize, Consolidate, Optimize.  I looked to Strategic Significance as a way that I could potentially provide a more nuanced technology strategy, that took into consideration that IT has more strategic significance to different parts of the organization.

Taking a broad brush approach – we could imply that IT is strategic to almost every modern business.  That being without IT capabilities much of the organizations functions would come to a halt.  However, what we really are looking at is most likely a wide-ranging application of tactical capabilities applied across the different business functions.  So, in this light, IT is as Strategic as a reliable Electric provider.

I think it is fair to say, that the Business Leaders assume that competent facilities people will keep the lights on, just as IT will keep their processes rolling along.  So, how strategic is IT?

What is Strategic Value

Strategic Value is about Competitive, Pricing, Cost, Product or Market Differentiation.  Wal-Mart’s strategy touches on three of these – Pricing and Cost are talked about widely.  Being the low-cost leader establishes a unique place in the market.  The can achieve this through their cost strategy, influence upon suppliers and the generation of Wal-Mart specific low-cost products based upon their buying power.  Finally, geographic spread – Wal-Mart is everywhere, is a part of a Market dominance strategy.

Strategic Relevance – When IT "Is the Value Chain"

So, when does IT take on the role of a Strategic Differentiator?   Ever here of Google or Amazon? There product is IT.  This is a bit of an extreme example, but the point is that the closer IT is to the Product or Service the more strategic it's value is to the organization.  In the absence of Information Technology what would their product be?  Even within the Amazon example, you can not diminish the capabilities that they have developed around order fulfillment.  This includes a lot of manual picking and packing, and they are very efficient in how they have implemented this capability.  However, if it was not for their ability to reach customers and match customers to products via the Web, they become a catalog retailer of the 1950’s.

Strategic Relevance – When IT is a "Part of the Value Chain"

When else do we see IT as providing Strategic Value?  A Recent story about Target and their customer targeted marketing has been in the news.  This is how Target uses Predictive Analytics to selectively market to individual customers based upon their buying habits and trends, in conjunction with some very sophisticated algorithms.  This allows Target to maintain mindshare and attract new customers, which they claim provides them with about a three-year attachment run.  Here we see this Predicative Analytics playing a significant role in Targets Marketing Strategy.  The capability is core to their Marketing approach for customer capture and retention.

So Strategic Value can be identified on broad terms where IT is the Business or as specific functional segments within the business.  The importance is how close the IT capability is to the actual fulfillment of the business strategy.  Both Amazon and Target see IT as strategic; it is just a matter of scope.  I am sure they both have General Ledger and HR Systems, but do those IT capabilities provide strategic differentiation?

Technology Archtiecture Strategy - Data Center Transformation 

So, if I am in an EA Engagement establishing the Architecture Vision and my scope is the Technology Domain, what are some of the tools I can apply to assess the strategic significance?

A reasonable place to start might be at the Business Architecture.  We need to establish our understanding of the Capabilities and Processes that drive the business.  Paul Silverstein has developed some useful models for evaluating business value vs. business scope – how much value the organization receives versus how broadly a capability or process impacts the organization.  Funding Models might be a useful piece of the puzzel as well.

By individually, assessing each capability we can define them in terms of tactical impact and strategic impact.  Next, we can evaluate each from the perspective of IT support required to deliver the capability.  We can start with the organizational alignment of IT and the business function to see to what extent the IT function is integrated within the business capability. Where there is tight alignment, we might want to highlight that capability for further analysis within the Architecture Vision Phase.  Funding models may provide us with insight concerning the functions dependencies on IT, and how much control the business function maintains over their IT capabilities.

Often we use Strategy Maps, and they provide value.  But what if I want to refine the assessment in order to establish tighter line of sight between functional stategies and IT.  I have seen some examples of balanced scrore cards used in assessing IT's relative value, but it tended to be applied very broadly.    I am suggesting that by assssing IT significance to the individual business function strategies in scope, we may be able to define a technology architecture strategy that focuses where the different standardization, consolidation, and optimization strategies will be most impactful, and return the greatest value.

Models and Tools for refining Strategic Alignment and Significance?

Are there tools you use for IT Strategic Assessment? 

I would be interested in hearing how you define the role of IT within your customer’s organizations, and how they determine strategic significance?  “Leveraging the New Infrastructure”, a book from Peter Weill and Marianne Broadbent, has some very interesting models depicting IT Investment to IT Impact.    

Do you have models or re-purpose models such as Balanced Score Cards to focus on IT value and strategic significance? 

Are there specific metrics that you or your customers find useful in defining strategic signifcance?  


Art, Artifacts, and Best Practices for Enterprise Architects


« March 2015