Monday Feb 13, 2012

Pats SOA Governance Perscription

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

New Papers from the OEA Practice

I wanted to make you aware of  several white papers recently authored by my colleagues here at Oracle. I hope you find them helpful in your own EA related activities.

 

Thursday Jan 19, 2012

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?

Tuesday Jan 03, 2012

Carpe Nube*

Cloud

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)

Monday Oct 03, 2011

Enterprise Architecture Tools; Another View

Tools

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 absentia, I thought I’d add my two cents to his sage post:

(http://blogs.oracle.com/enterprisearchitecture/entry/tools_of_the_trade)

There are several very good EA tools on the market, but each come with their own learning curve and, as Eric mentioned, there can be variance in usage across companies - ranging from no standardized EA-specific tools to adoption of one such as Troux.

Having said that, here are the tools that I think are basic / fundamental in an Enterprise Architect’s tool box and how they can be used (or at least how I use them).  Idea is to embrace, but extend what Eric said.

Tool

Use

Spreadsheet (such as, but not limited to Excel)

Capturing everything about the project such as organization structure, divisions, current costs, etc…).  Once it is in the spreadsheet, it can be sliced and diced and, importantly, imported into the presentation software to make clear the facts that went into the current/future state positioning.  Also key to making a business case for any initiatives to be undertaken.

Presentation Software (such as, but not limited to Power Point)

Communication, communication, communication!  Getting everyone on the same page through information roll-ups, diagrams and architectures is really at the heart of what we do.  Yes?

Oracle JDeveloper / BPM

This is great for sketching out a business process in BPMN notation which (unless you NEED a L0 – L2 model) is a pragmatic way to flesh out current and future state business flows.  The added benefit is that, with Oracle BPM 11g, Business Analysts and Developers can begin to collaborate on fleshing out your model once a business process automation project gets the go-ahead.

Sure, you have to download a development environment but, hey, it’s free and relatively easy to use tool.

Whiteboard Markers (such as, but not limited to Expo markers)

Nothing works better than getting people in a room and working through a particular topic in a collaborative fashion.

Hint from personal experience: make sure they are dry erase and not permanent. 

Well organized file system (such as, well…you get the idea)

The more you do this stuff, the more you have a library of tried and true materials that are battle tested.  Try to organize them well on your disk (or do what I do and catalog things in a spreadsheet with hyperlinks  to the files – one of my secret tricks)

So, that is my story.  But, I may likely not stick to it....

Monday Sep 19, 2011

Tools of the Trade

So recently my buddy over at OTN Bob Rhubart asked, “What tool or tools are indispensable in your role as an architect? When faced with a new project what's the first thing you reach for? Why?”. I instantly protested regarding the brevity of the answers. He suggested I blog about it. So here goes.

So the Miss America answer is I “reach” for my eyes and ears. Listening to the customer’s needs and pain points is vital to ensuring a resultant architecture is in alignment with their business objectives and is attainable within their cultural milieu. I need to approach each engagement or initiative with a fresh, clean slate and record everything I hear or see. I can’t help but liken the job to that of an archeologist or crime scene investigator - especially when focusing on current state architecture.

For practical tools I look to a metamodel to determine what type of information am I trying to collect. It depends on the corporation or framework I might be working with, but the metamodel provides me a sense of completeness in what I’m looking for. Its a great way to catalog current state observations and look for trends, redundancies, and sub-optimizations. When creating a set of future state renderings, it allows me to parse out future capabilities and map them to goals, drivers, and other objectives.

So how do I track this information? I use Excel to track catalogs and matrices of the information in the metamodel. Optimally I would pump this information into a repository-based EA modeling tool like Troux, or MEGA. But not all EA programs have made the leap to these tools - many are still relying on PowerPoint/Visio (or OmniGraffle for us Mac folk). If I really need to do some extensive analysis - and its happened at least once - I’m able to export to CSV files and put them in a database and use my SQL-fu to come to an answer.

As digital as I have become with an iPhone, iPad, and MacBook, I still rely on a bound notebook for taking notes - especially during customer conversations. The linearity of (spectacular) programs like Evernote, OmniOutliner, or even MindMap Pro just doesn’t work for me during discovery sessions. The information is not in a linear outline. I need to draw arrows all over the place. I need to instantaneously switch back-and-forth between writing text notes and drawing pictures. And batteries will eventually die or the flight attendant will bust me during takeoffs and landings…

So there you go. A metamodel, Excel, and a good notebook. That’s my answer, Bob, and I’m sticking to it.

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!

Monday Aug 08, 2011

Six Reasons Why EA Should NOT be Assigned to the IT Department

Elements of Style

This is such a poignant post that I felt compelled to repost it here.  In a Linked in blog post by: Pallab Saha, he clearly positions why EA is a superset of IT architecture and why the two need to be kept separate.  I am reminded of my study of Strunk and White’s The Elements of Style – the classic treatise on clarity and brevity of written expression.  Pallab nailed it in these collection of key points:

Six Reasons Why EA Should NOT be Assigned to the IT Department

6. EA ≠ IT Architecture

5. True EA leads to redistribution of authority, which is beyond CIO jurisdiction.

4. EA value proposition (i.e. standardization vs. innovation) is solely business realizable.

3. The primary goal of EA is to build coherent enterprises, not better IT systems.

2. Synthesis takes precedence over analysis.

1. EA failure is an organization failure, not an IT failure.

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 28, 2011

TOGAF Certification - more

TOGAF Books

I have been getting a lot of questions about how to get ready for TOGAF.  The 2 previous entries have some good advice about training classes and how to study.  I will add (and reiterate) that the single best thing you can do after taking the training class is to

1) get the book and read it over and over so that you go from familiarity to really knowing the material (I found the physical book better for studying than the electronic book).  The smaller study guide was not of as much use  other than the fact that it summarizes things well.

2) get the sample tests and quiz a “study buddy” back and forth.  My buddy and I blasted questions over instant messaging while we were on the phone talking over our answers

Hope that helps (more)

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.

http://chriseaton.files.wordpress.com/2009/12/togaf-9-multiple-choice-questions.pdf

http://chriseaton.files.wordpress.com/2009/10/togaf-9-scenario-questions.pdf

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.


Wednesday May 18, 2011

Combining SOA and WCM

A good friend of mine was in town this week to visit one of his clients.  When we got together for dinner (and, yes, drinks) one of the topics (inevitably) was architecture.  Lately he has been working with some very large international companies re-architecting their public web sites to flexibly deliver localized content.  The solution was to combine Service-Oriented Architecture with Web Content Management.

In a nutshell, the architecture includes a web front end that is composed from portlets where each portlet requests content from WCM system(s) using WSRP.  The front end is de-coupled from the WCM systems via a service bus where the service bus is responsible for routing the content request to the appropriate WCM system.  (I’m using the term “service bus” here in the most generic sense, not to denote a specific product.  My friend prefers the term “service fabric”.)

This has an obvious advantage for localized content.  The service bus routes the request to the correct WCM system based on the chosen local.  This allows each division, country, or geography to manage its own content yet the corporate web presence is still unified.

Another advantage my friend pointed out is that this architecture simplifies previewing of new or modified content.  The service bus can route content requests to a staging WCM system for users that are responsible for reviewing new or modified content.  The new/modified content can be viewed directly in the production web site before being “published”.

It figures that I’d have this conversation *after* writing the ORA User Interaction document (a part of ITSO).  Nonetheless the ORA User Interaction document does cover these topics albeit not this specific usage.  This architecture is a specific example of what is denoted generically as “federation” (e.g. section 4.2.3) in the document.

Tuesday May 17, 2011

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

 

[Read More]
About

Art, Artifacts, and Best Practices for Enterprise Architects

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today