Enterprise Architecture in Higher Education

Mike Kavis posted another great piece on why we should use Enterprise Architecture. As always, Mike has some real gems in his post.  Here are a some:

• “It sounds to me like people have a technical solution and are now looking for a problem to solve with it.  It needs to work the other way around!”
• “Well, coming to the business with technical solutions asking for help to justify them with business drivers is not alignment.”
• “At this point the ROI should be much easier, because the solutions were driven by the problem statement(s), not the other way around.”
• “Without this alignment, IT will constantly struggle to sell technical solutions to the business and come up with appealing ROIs.”

With the recent economic situation, business leaders are looking more and more to IT leaders to help enable cost savings and business performance. In my regular meetings with my business colleagues, this is becoming a consistent theme. The only way this will happen is for IT leaders to sit with business leaders and understand their issues and problems.  Once this problem is understood, then the  IT leader can bring to bear the appropriate technology solution.  The ROI is put back on the business (where it belongs) and how the problem is solved not on the technology that enables the problem solving.  Read more...

Recently, we have been talking about creating a single repository for IT Services departmental information. The idea being that our team members need to go to one place to get the information they are looking for. Instead of wasting time looking at multiple repositories each with their own taxonomies, UX and search features, put it all in one place with one UX and taxonomy.

Today, my thinking took a 180 degree turn with a vendor presentation on “enterprise search“. Instead of making people conform to rigid rules about where to put information, what if we gave them a tool to find the data wherever it resides behind our firewalls? Like someone said today, “Google search for our stuff”

No some of you might say, not taking time to architect an information repository and relying on a search engine is the lazy way out. I have some thoughts that I hope will make you think otherwise. When presented with business challenges, I find it is rarely the technology that is the problem. Instead, it is the ease of use for our clients, customers and stakeholders that should be considered. Enforcing compliance is expensive and in many cases ineffective.  What if we made it easy for people to comply? Educate them on some simple tagging and then let them work like they always have.  The difference is giving them a tool to search for what they need and work to tune that tool so that we see a significant reduction is costly “Search and not find” scenarios.  Read more...

Alan Inglis posted about What good looks like from a solutions architecture perspective.  How do you create a solution for a new project without creating architecture that already exists or making the same mistakes that previous projects made? This is a must read post and I recommend it.

Alan described 10 artefacts that he would expect a solutions architect to leave behind from a project implementation. They are:

1. Project Background
2. Terminology
3. Key Drivers, Principles, Standards and Constraints
4. Business Problem
5. Information View
6. Risk View
7. Application View
8. Data View
9. Integration View
10. Infrastructure View

I have some questions for Alan on this:

• How big a project would require this level of artefact creation? For small and possibly medium projects, the work to do the architecture may be more than delivering the project.
• Is there a subset of these artefacts that would be sufficient for small and medium projects?
• How would the next solutions architect find and assess the artefacts created?  Need a searchable, secured repository – wiki?, blog?, SharePoint?, network file share?, knowledge base?

We, Enterprise Architects, regular trumpet the value of having an archictecture and learning from it.  Some of the key factors for me would be:  Read more...

JP Rangaswami posted an interesting entry on Build versus Buy versus Opensource.  In it he states:

“And the way I think of it is this:

For common problems use Opensource.
For rare problems use Buy.
For unique problems use Build. ”

Not bad but I really think he missed a fundamental part of this discussion.  Reuse should always come first. Look at what you have in people and their skills  and technology already deployed that could deliver the solution.  I think my post on EA Guiding Principles  better addresses the need for reuse.

Thoughts?

For years, I was convinced we worked as solutions integrators or systems implementors in the application development (enterprise and web) groups. I was wrong.

Our major software (SungardHE Banner ERP) is an Oracle based COTS (Commercial Off the Shelf) application and our collaboration software comes from IBM – Lotus Domino. We would make certain mods to the applications for example to “Canadian-ize” Banner Finance for tax rules but for the most part would implement as close to baseline as possible. Since starting the EA practice @ BCIT, I began capturing, documenting and analyzing information on our application architecture.

Here are some stats from our May 2007 Application Portfolio showing number of applications based on Application Development Environment:

Apps by Application Development Environment

PHP 47 <—————- BCIT developed
Proprietory 38
Domino 38 <————- BCIT developed
PL/SQL 22 <———— BCIT developed
Oracle Forms 14 <——- BCIT developed
Java 13<—————– BCIT developed
HTML 6
IWR 3
MS/Access 2
Open Source 2
MacOS 2
Discoverer 1
Impromptu/Powerplay 1
LDAP 1
MS Exchange 1
Cognos IWR 1
N/A 1
Windows 1
none 1
Novell 1
Oracle Forms/PL/SQL 1
Oracle Forms/PL/SQL/PHP 1
SQL/Server 1
Multiple 1  Read more...

We have just completed the second update of our Application Portfolio. The results are very interesting. I want to thank all the IT Services staff who contributed to making this piece of our EA real!

Here is a table with some of the significant changes from November 2006 to May 2007:

I will post more about this later including my rethinking about what kind of IT shop we work in …