Pat Shepherd

Enterprise Architecture Tools; Another View

by

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

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

by

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.

Vanilla Apps – An EA's Friend

by

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 …

Vanilla Apps – An EA’s Friend

by

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

 

TOGAF Certification – more

by

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 taki…

TOGAF Certification – more

by

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)

Passing TOGAF

by

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 materi…

Passing TOGAF

by

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 materi…

TOGAF Certification

by

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.  Chec…

TOGAF Certification

by

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.  Chec…