EA Governance

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

by

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!

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

by

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!

Soft Skills, Leadership, and now Empathy

by

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?

Soft Skills, Leadership, and now Empathy

by
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?

Pats SOA Governance Perscription

by

RX 

Just recently, I was asked to provide some advice to a customer on how to adopt SOA Governance, specifically the Oracle Enterprise Repository (OER), in a step-wise and rational way.  It seemed like sage enough advice to publish here

Here is what they were trying to do which is similar to what other customers are doing:

  • Establish a single source of truth in a SOA Repository
  • Single repository supporting on-shore / off-shore distributed teams
  • Manage service artifacts (i.e. projects, service design documents, policy definition…)
  • Enables SOA program managers manage service portfolio and service demands
  • Enables SOA program managers with related reports (i.e. demand, reuse, compliance & exceptions, dependency/impact analysis, …)

So it can be successful – but you don’t want to boil the Governance Ocean – at least not all at once.  In a word, I’d advise getting a firm understanding on which services you want to govern (probably not all of them) and the types of things you want Governance to do for you. Once you have that, you can move forwards in a stepwise approach that reduces the effort AND complication.  Realize that installing OER is only a small part of the puzzle.  You need to have the right Org structure (official or unofficial) in place and the right incentives and rewards to help motivate people to “do the right thing” such as to reuse services instead of writing their own.  Then you need the right processes to for people to follow.  It’s the notion that:  

 Governance = PEOPLE + TECHNOLOGY + PROCESSES


Let’s say there are 50 key services to manage –  for discussion purposes.  Here is what I’d do at a super high level:

  • Add Projects, Policies, Classifications Asset Types as needed (JUDISIOUSLY – keep it simple at first)
  • Add users in different roles
  • Get your top 50 key existing web services in OER using the Harvester if possible.  Otherwise just take some time to add them manually.  Make sure these are the relatively static PROXY services from OSB.
    • Be sure to assign one or more people to OSR as administrators/architects to help keep things in order
  • Add the correct lifecycle stage to them
  • Add the right classifications/taxonomy to them
  • Add documentation such that developers know how to use the service (i.e. can download a doc or visio or whatever that explains it)
  • Add any and all XSD, WSDL and other files that people would need to download to actually use service
  • Add a section to the OER home page that explains to users about the WL Gore SOA program, schedules and contacts – make it a place people go for some critical PROGRAM-level information – SELL what you are doing here…
  • Get developers used to using the tool through an in-house training
  • Use the reports to get a management view into the SOA program and help fund/support what you are doing
  • Then – start entering future state services to track as they go from inception to deployment in the life-cycle

 

Things that add complexity that you can add later IF they add value to what you are trying to do:

  • Install OSR / set up
  • Enable publishing to OSR
  • Set up harvesting of SOA/BPEL projects
  • Set up/enable automated approval workflows
  • Synch up performance metrics from OSB or OEM back into OER
  • Assign CAS (custom access settings) settings to individual assets

And so on.  But add these later after the basics are down.

So – I hope this helps anyone else who wants to begin a SOA Governance effort using OER (with OSR, OSB and OEM as secondary stages after initial success).

EA Governance – Architecture's Sustainability

by

One of my fellow consultants here at Oracle had a great quote the other day regarding EA Governance:
“One cannot overstate the tedium nor the importance of EA Governance”
For those in the EA discipline that “grew up” through more technical disciplines …