Application Portfolio | Enterprise Architecture in Higher Education

Business Analytics Anyone?

enterprise architecture, higher education, strategic planning No Responses »

Jan 112012

Today, I participated in a focus group to help start up the BCIT School of Business Business Analytics Centre of Excellence. The room was full of Business Intelligence/Analytics/Insight leaders from around Vancouver. We were brought together by Ed Bosman and Karen Plesner both instructors in the BCIT School of Business. Karen facilitated a two hour discussion on a series of topics. The group provided advice on the skills expected of graduates in the various business analytic roles – consumers, artisans/analysts and systems technicians. The other major focus was on what a “centre of excellence” for business analytics should provide and deliver to industry.

We were provided with a definition of Business Analytics as the seed for the discussion:

Business Analytics: the skills, technologies, applications and practices for continuous iterative exploration and investigation of past business performance to gain insight and drive business planning (Davenport and Harris, 2007)

This definition generated a very good discussion and the consensus was that this definition was too narrow. It failed to address real-time analytics for operational performance management and web analytics for customer behaviour management.

We had a good discussion about master data management and data standards. One of the great quotes of the day came from an panel member. He was referring to a discussion about how confident and accurate your numbers need to be. I really like this pragmatic approach.

Business Analytics augments your gut

The another panel member introduced the group to a model used by Davenport and Harris. Here is what it looks like:

Davenport and Harris Model	Information	Insight
Past
Present
Future

The model is a measure of where business analytics efforts are focused. This would be a good model for us to look at the maturity of our Business Intelligence/Analytics practices.

This table contains the lists of topics and themes I noted during our focus group. There are many topics and themes below that will warrant future blog posts.

Trends	Tools	BI/BA Type	Audience
Web Analytics	Excel	Operational “Real time”	Consumers
Mobile	Access	Tactical “Just in Time”	Artisans
Bring Your Own Device	Qlikview	Strategic “Points in Time”	Analysts
Security	Tableau	Compliance	Authors
Privacy	SAP	Predictive	Systems Technicians
Predictive	IBM Cognos
MDM	MS Analysis Services
Big Data	SAS
Information Overload	SPSS

I am looking forward to the next steps in the process and hope to contribute to the effort.

Davenport, Thomas H.; Harris, Jeanne G. (2007). Competing on Analytics: The New Science of Winning. Harvard Business School Press

Reorganizing An Application Service Delivery Model – an update

enterprise architecture, it governance, management No Responses »

Aug 022011

I wrote a post titled How Would You Reorganize an Application Service Delivery Model? in March 2010 and thought it was time to update you on the changes we made to our Application team.

At that time, my team was structured by role: DBAs, Developers, Application Administrators, Email Administrators, etc. Over that time, we had some successes with the structure and some challenges.

Some challenges with the role based structure included:

separation of developers and DBAs – resulted in delays, rework when developers did not meet coding standards expected by DBAs, and disconnected teams
separation of services that had tight integration like our portal environment from the ERP platform
mixture of platform skills that caused service support issues when service recovery work crossed team boundaries
challenges in providing minimum staffing coverage and training when support spanned team boundaries such as Identity Management, Project Management and Business Analysis work

In September 2010, we had an opportunity to reorganize our team. After consulting with our team members and team leaders, we changed the structure to suit the two main architectures that our team supports – Microsoft and Oracle. Essentially, we moved the developers to the platforms they predominately worked in and realigned the services that required tight integration.

Comparison of Role Based Structure to Platform Based Structure for Application Services

Role Based Structure		Platform Based Structure
Support Team	Oracle DBA	Oracle Team	Oracle DBA
	Document Management		Business Intelligence
	Business Intelligence		Document Management
	Project Management		Enterprise Portal
	Business Analysis		ERP Administration
	Identity Management		Java/Web Services Developers
			Oracle Developers
Email and Collaboration Team	Email Administration		Identity Management
	Calendaring		Business Analysis
	Instant Messaging		Project Management
	Collaboration Platforms	Microsoft Team
	SQL Server DBA		Email Administration
	Microsoft Applications		Calendaring
	Enterprise Portal		Instant Messaging
			Collaboration Platforms
Developer Team	Java/Web Services Developers		SQL Server DBA
	Microsoft Developers		Lotus Domino Developers
	Oracle Developers		Microsoft Applications
			Microsoft Developers
			Identity Management
			Business Analysis
			Project Management

We have been running with the structure for almost a year now and are seeing the benefits of aligning our Application Services team with our main support platforms. I will revisit this structure annually to ensure that our team is organized to best serve our client community.

Build your Application Portfolio to Support EA Governance

enterprise architecture, it governance 2 Responses »

Jul 252011

Nick Malik wrote a great post titled The Rule of EA Governance that hits to the core of EA and IT governance. It is a must read and I highly recommend it. Nick asserts that:

All Enterprise Architecture will be implemented according to the structure of ownership and governance that exists in the enterprise.

Next Nick explains why this is important by using an example of a CRM implementation in an organization. He specifically states that:

If you have two business customers who both want a CRM solution, and you have one governance body, you will end up with one CRM system. If you have two governance bodies, you will end up with two CRM systems. If you have four business units who want CRM, and you have three governance bodies, you will end up with three CRM systems.

This rule plays out repeatedly. I’ve never seen it fail.

The failure to recognize “The Rule of EA Governance” is one of the causes for the failure of an EA program.

I too have seen this throughout my career and my work with multiple organizations to introduce enterprise architecture practices. We have seen many reports and stories about how EA programs have failed and I completely agree that a lack of ownership and governance contributed to the failure.

Now I want to suggest a practical approach to help your EA practice make “The Rule of EA Governance” tangible. Build an application/service portfolio and ensure that you associate an Executive Sponsor and a Business Owner to each item in the portfolio.

Once you have done this, start showing it to people … it is amazing when people see their names or their departments associated to a particular thing how interested they get! Nick had a good quote:

The business doesn’t care about nice drawings and great designs. They care about “stuff they own” and “stuff they don’t own.”

If people never see what they own, how can we expect them to govern usage especially when it is a shared service? Nick ended with an approach to help all of us move our Enterprise Architecture practices forward:

So if you want to know if your Enterprise Architecture can be implemented, count the “things” in it. Then count the number of those things with exactly one owner (and clear governance). Those are the things that will be implemented just the way you describe it. Everything else is a free for all.

Simple and brilliant – thanks Nick! Read more...