4 years, 11 months ago

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, hav…

5 years, 2 months ago

Pats SOA Governance Perscription


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:  


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).

5 years, 3 months ago

Enterprise Architecture vs. SOA Architecture Part III

It’s nice (and humbling) to know that people read one’s blog.  I got a note from a reader that said:

“I understand that SOA is more concerned with business services integration and EA is concerned with dealing with enterprise-level infrastructure and business components.

If you could, would you be able to provide a brief definition of them both in your own words that clearly distinguish the differences? (that’s different from my one?)”

Good question.  SOA, I’ll give it a try (forgive the pun).  This is strictly off the cuff, my cuff, recognizing that there are plenty of places to dig up various definitions of the two.

Enterprise Architecture – The documenting and mapping of corporate strategic initiatives and strategies to the technological underpinnings that need to be in place to optimally deliver on those strategies.  What makes EA more than an intellectual or academic exercise is that it provides the governance scaffolding to ensure that the required work gets done to plan and deliver on required/key IT products/services/capabilities.  Importantly, EA is not focused on any one technology or technology bucket in isolation, but how they work in consort to ultimately provide business capabilities.

Service Oriented Architecture – An architectural approach to creating software applications and system integrations which focuses on the notion of Services; reusable software components that leverage open standards.  This provides a vehicle for companies to create applications more rapidly than ever before through composite service assembly/orchestration.  Because they are Service-based, they are, at the same time, more flexible. Though SOA itself has nothing to do with any specific technology (it is architecture and an approach), Service creation/assembly/orchestration is often enabled through technologies such as Java, XML, and Web services.

Is that useful?

5 years, 3 months ago

Carpe Nube*

Enterprise Architecture is more important than ever with the increased adoption of Cloud Computing.  Most companies that I work with have a range of systems and initiatives that span the continuum of “must stay in house” to “this is best …

5 years, 3 months ago

Carpe Nube*


Enterprise Architecture is more important than ever with the increased adoption of Cloud Computing.  Most companies that I work with have a range of systems and initiatives that span the continuum of “must stay in house” to “this is best run in the public cloud.”  There are 3 types of Cloud Models:

  1. Private Cloud (we like cloud, but need to manage it ourselves because of security/cost/agility/etc.. reasons)
  2. Public Cloud (here are the systems we need, we will pay you to run it for us)
  3. Hybrid Cloud (some systems we need to keep in-house but for other stuff it would be cost effective (or cost avoiding)  if we did not have to run/maintain them ourselves)

In all cases, Cloud is an IT operational model (what systems run where) that is driven by business needs and imperatives.  Even if you go 100% Public Cloud, you still need to make sure that the Applications and Information provided by those systems are meeting the ever changing business needs.  The Hybrid Cloud model provides even more complexity because applications, communication, integration, data flow, and security need to be coordinated across the Cloud boundaries. 

Enterprise Architecture is the glue that can help keep all of these things together and is why Cloud Computing does not get rid of the need for EA, in fact, it is this humble author’s opinion that it dramatically increases the need of EA stewardship over Cloud.

* (Latin for Seize the Cloud)

5 years, 6 months ago

Enterprise Architecture Tools; Another View

Eric Stephens, my friend, and fellow Oracle Enterprise Architect, recently blogged on the subject of “Tools of the Trade” of Enterprise Architecture.   I was invited to the same podcast as he was, but could not attend.  So, in abs…