In business the context usually looks like this: “Customer àBusiness à IT” and this can cause major problems in planning cycles. So if and how can one identify predictive statistics and employ them to reduce the lag and have IT & business together calibrate to customer needs quickest?

There’s no magic bullet but Weiss puts forth some greatly helpful suggestions in the “Introduction to Business Context” article. Since every organization is different each organization should pay attention to environmental trends first and also stay on top of emerging technology and trends also. Paying attention to these will help business and IT stay future focused. This also means staying on top of the Common Requirements Vision and updating it at least yearly. It is essential that EA teams revise the CRV frequently especially as the pace of technological improvements increases.

The one Weiss quote that sticks with me most is the following: “The business context is the step in the EA process that combines the analysis if environmental trends and the business strategy and directs the EA team effort in the creation of the future state.”

EA Measurement - How not to fail

Measurement is critical to any business initiative in today’s business climate but the mountains of data collected by various business applications can also be detrimental. Agonizing over metrics can reduce speed to market, by creating a culture that needs to “fully” analyze data before decision making. Gartner’s “Why EA Measurement Programs Fail provides a simple high level viewpoint of what to avoid when constructing measurement programs. The validity of the article became apparent when looking back at a past business interaction from several years ago.

Management wanted to institute a new time management program and track time everyone in our division was spending on various activities. Sounds all fine and good, right? WRONG. Management decided to have everyone track their time in 6 minute increments (one tenth of an hour) because that was what other companies were doing and justified it by stating it was  industry standard. It was a way to reward our productivity and gauge the IT tools provided to us. That’s not how it was perceived by the majority of the employees and this effected the results of the measurements.

One of the core tenants of the company had always been having a client focus and to the employee base this new time tracking standard was seen as micromanagement. It took away time from clients and put an undue burden on the employee to manage this active metric (most metrics gathered by the company were passive). After a few weeks of adoption and correction to standardize the compliance department who was running the time tracking measurement program touted their progress and how the program was giving them insight into how time was spent for projects vs.  support vs. administration.

However, there was an elephant in the room they could not see. There were no controls around how employees were entering their time. After being questioned on “why an entry was a certain way” and/or “what one was doing” employees began constructing their time cards in a way that corresponded with what the compliance department wanted to see. There were few controls around this active metric so compliance thought they were seeing improvement when in fact all they were doing was scolding employees into cooking their timecards. All of the employees were on salary so it had no effect on payroll dollars, but invalidated all of the measurement that was being done by compliance.

The measurement program was not well explained, aligned with the company culture so it was not trusted by the participants. Needless to say it failed after a couple of trying months. Measurement programs must be well articulated to those being measured in order to build trust in them and around them. If the participants can see the program is designed to furnish them with better tools and the right resources for success – the measurement will have value and garner support. 

Works Cited

Weiss, D. (2006). Why Enterprise Architecture Measurement Programs. Stamford: Gartner .

Governance in IT Projects

Over the course of the last several years as project manager I’ve seen an increased interest in data security and this is a wonderful thing. After several high profile leaks of personal information companies across the world are finally understanding the need for a practical and deliberate approach to governing company-wide IT systems. It’s not flashy, it’s not going to get customers to love you but it is a cost of doing business. On top of that if you don’t do it, you might not have a business to run if things go wouth. The quickest way to lose credibility is to be wreckless with something someone else values – not to mention if it’s something personal – and every person involved in the EA governance process should know that:

We are steward of the data we collect – we don’t own it.

Adoption of EA processes including an ARB and a robust governance process is integral to standardizing security controls across a company. The ARB must perform a risk analysis and vet each and every project according to its level of risk and complexity. It is imperative that EA team befriend and work closely with project teams to understand the scope of each project because EA program should not be involved in day to day project work. EA should act as gatekeepers at major milestones of the project or at the very least during the planning and closeout stages of projects. Too much EA involvement can be as bad as too little.

So keep it simple – where and whenever possible. 

Roadmaps and SaaS

Continuing from last week’s post about Old roadmaps being dangerous this week I’m going to explore some thoughts on how the increase in subscription based SaaS applications can affect EA roadmaps.

So how do Cloud based SaaS technology affect EA roadmaps?

The power of SaaS lies in the fact that the purchasing company doesn’t own a soon-to-be outdated technology. The cost of the applications is spread usually across a number of years and as the software vendor updates and upgrades the application, these features are made available to the purchaser. This means for outsourced services like purchasing or HR software the EA team needs to keep aware of the SaaS vendor’s roadmap and identify if it affects their own. Also, at the expiration of the contract the EA team should be evaluating that SaaS and making a recommendation on how it fits into the current and future company EA.

This breaks the old model of: Emerging à Production à Legacy à Exit.

A good SaaS company stays relevant through the adoption and deployment of new technology so the application never reaches the legacy stage without a major market shift. Yes there will always be new trends but companies will always need to manage the HR process and purchase items. The question is how can the SaaS enable and automate those processes so company employees can spend their time doing what the organization hired them to do. In addition, a company only needs to administer SaaS and not maintain the code freeing up IT and EA resources to focus on the company mission.

I see the new model as: Implement à Deploy à Adopt à optimize (and don’t stop)

Unless there is a strong reason to implement a new solution, companies who leverage outsources SaaS applications can stay in the optimize phase. To me, there is a strong value proposition in in the reduced costs of optimizing versus implementing a similar solution every few years. Your get new tools right away, the key is being agile enough to pick them up and use them. 

Old Roadmaps are a Dangerous Thing

Old Roadmaps are a Dangerous Thing

I think I have seen about a thousand roadmaps over the course of my career, some great, some needed to be burned. Having a time phased plan for improvements is critical to the success of any business but what is just as important is how often that roadmap is reviewed and how flexible an organization is with that plan. Roadmaps like many EA artifacts can quickly become dated so EA teams must be ready to make a new plan as market conditions and technologies change.

Once upon a time I knew a Senior VP of a company and he was incredibly inflexible even in the face of strong evidence that market conditions were shifting. He still lived in the word where technology was something that helped the business run but did not have the role of connecting the organization to the customer. He had a talented and experienced IT Corporate IT team that could have transformed the organization into an industry leader but lacked the vision. His roadmap looked like the ones that had been presented for the previous 10 years, so results suffered.

So where did he go wrong? What should he have paid attention to? Did he miss a roadsign?

1) Company and EA Leaders must be visionaries. No vision = your company is roadkill in today’s Hyperconnected economy.

2    2) One needs to be able to translate that vision into incremental activities that are appropriately stratified.

      3) Roadmaps are necessary, but like Rand McNally they have to be released a minimum of once year.

      4)  The new roads, while less traveled are the ones EA and company leaders need to be aware of. If you are that proverbial gas station on the corner or Main and Park and there’s a new interstate allowing traffic to bypass that intersection, time to rethink your roadmap.

      5)  If there’s construction (market turbulence) make sure your roadmap reflects this. Will it last for one year, or five?

      6)  If there’s no good roadway option, maybe it’s time for a new road. 

      Have a safe and happy Independence Day