Culture is everything - Signing off

The most important part of EA is having fun while doing it as no one will want to be part of an EA initiative that doesn’t. In every business there are compliance requirements and mandates that require teams to do work they might rather not which is why having the right culture is so important. Is it imperative that the Chief Architect sets a tone that makes the EA process approachable because this will lead to increased participation and cooperation. If stakeholders dread your meeting then they will find every possible reason to get out of it and pretty soon they will delegate their role to a subordinate if they can. Shortly afterward one will have room full of subordinates instead a room full of decision makers and every time a decision needs to be made each subordinate will need to scurry back to their boss for feedback. Of course since the boss hasn’t been to the meeting and probably hasn’t read any of the emails guess what… Someone gets to explain to him or her second hand what’s going on. It’s like a bad game of telephone but with really important stuff. And if a single participant is causing the EA meetings to take the wrong vibe – get rid of them. I’m not saying get rid of the problem stakeholder necessarily – I’m saying call them out and then tell them if they are not on board, there a door in the room they can choose to exit from.

So think about the following each time you schedule a meeting: are all the participants really needed or are you just sticking to a list of everyone. Be a good steward of people’s time and they will be grateful for it. Next time you schedule a meeting that they really DO need to attend then they will be receptive to the request. This is especially true if the EA meetings have a good tone. It’s just EA – no one is going to die if things don’t turn out perfectly and mistakes will be made. This should be expected as EA is an iterative process through which value will be increasingly apparent as the EA initiative grows in maturity. Articulate and document the value EA brings in a way that is not debatable except for the amount of value it brings: significant or very significant. I’m not saying it  will be easy as most things in life that are valuable are not but perception is reality to most in today’s hyper-connected world. The perception that EA is not culturally aligned with an organization will kill the program as fast of not faster than if one has a poorly designed and executed program.

So make EA fun and people will spread that good word around the water cooler.

Perception = Reality.

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 

Vision in Project Management: Bridging the Gap Between EA and Project

There are so many details in IT Application implementations that many EA Teams do not have the time to be involved with. This is a critique, not a criticism. Many decisions are made “on the fly” by the functional lead along with consensus by the rest of the group but this can be problematic. Quickly made decisions lead to quick action but that does not mean the time has been taken to evaluate the appropriate viewpoints. To truly address this, a cadence needs to be established that bridges the various constituencies, with a “just enough, just in time” approach. Phasing meetings throughout iterations of a project consistency in the exchange and evaluation of ideas from multiple levels of an organization. This includes regularly scheduled feedback loops through which EA team members can act as gatekeepers for the local project level decisions.

Additionally, the stratification of each meeting should scale across meetings so that non-pertinant stakeholders are not involved in discussions that don’t require their input. Being respectful of each and every parties time, large and small, will win a project manager’s favor. The establishment of that trust can be a foundation that the EA team builds with a vendor concurrent with the implementation. A project manager is a relationship builder and E A teams should take the time to integrate EA tasks into their actives.

EA teams should use Vendor Best Practices to Shake the Tree

A Best Practice Configuration is something that many Software as a Service companies bring to implementations but in my experience getting clients to adopt them is difficult. Personally I believe this is a byproduct of the paradigm shifts between old school On Premise products and the new school Cloud Based solutions. In order to service the greatest number of customers and implement in the least amount of time some level of standardization must be achieved and leveraged. This also leads to client pain points when their internal processes don’t align with vendor best practice, or their EA program is not well developed.

Having EA guidance when choosing a vendor is a practice most organizations follow but their continued support through the implementation is where additional value can be found. EA teams should provide guidance and governance on project teams, not just take a supplementary role. Waiting for project team members to ask for EA assistance ignores a common problem: without EA being fully involved in project activities project team members unintentionally miss opportunities for EA involvement. Application implementation often involves several functional teams such as H.R., Accounting, Compliance and IT and understanding those interactions are critical to the process improvement that lead to improved Solution Architectures and new iterations of the Future State Architecture. In my experience functional departments are the slowest adopters of change and often hold on to a way of doing things because they are comfortable with them not because they are actually optimally configured.

EA teams should use implementations to further realize EA value and adopt vendor best practices when possible. By actively participating they will make functional departments accurately articulate their needs rather than accepting the status quo. By challenging them, and then listening, EA teams will gain a greater understanding of not just what these departments say they need, but what they actually do.

The Shift from On Premise to a Cloud Model and EA

Getting involved in the strategic planning of an organization is essential for all EA teams but in order to make the greatest impact. EA teams needs to consider how the strategic shift to cloud based applications affect their planning and implementation cycles. Over the last several years software giants have slowly began to embrace and implement cloud based solutions even for core IT systems such as ERP, CRM and HR. Cloud based applications are sold on a subscription model which allows EA team to set terms of those contracts and also more effectively plan for when procurement cycles need to occur for various enterprise applications. Furthermore, with more frequent product releases and approaches such as agile scrum organizations need to be increasingly ready to incorporate new product features into business models if they are to keep up with the increasingly changing marketplace.

 In the past, an ERP system might be used for 10-15 years with few changes in capabilities. EA teams built documents and aligned strategy around what the ERP could do and this worked. In the next 10 years as most companies shift to cloud based applications for the majority of their core systems it becomes incumbent on EA teams to modify their approach with more frequent updates to the “Future State” model to reflect these changes.

Heller does a great job of reflecting on this in an Oracle centric way in Public Cloud: The Next Frontier of Enterprise Architecture ( http://www.oracle.com/technetwork/articles/entarch/oeea-public-cloud-next-frontier-2400599.html ). He points out that data integration, business process understanding, security and finally business intelligence are four dynamic challenges that must be managed if organizations are going to succeed in building a competitive advantage. The standardization of these many applications in a Cloud Suite can be a powerful tool for many of their clients, however there is a bit of nativity related to organizations purchasing their IT products from one vendor in a Stack as suggested. No one company is best-in class in every aspect as there are many vendors who unlike Oracle focus on verticals or micro-segments of the overall software market. In the future to avoid the problem of middleware ERP teams should consider and purchase products that offer connectivity outside of a product stack of one of the software behemoths. Every organization should be able to purchase and connect the products that are the best for the business needs of their organization without constriction. Software companies who support this flexibility will lead their individual markets as I believe the software stack will wane in strength within the marketplace.

EA teams can’t wait for this to happen to change their thinking and should always seek the best solution for their business.

Works Cited

Heller. (2015, January). Public Cloud: The Next Frontier in Enterprise Architecture. Retrieved June 2016, from Oracle : http://www.oracle.com/technetwork/articles/entarch/oeea-public-cloud-next-frontier-2400599.html

Operating Model Changes Must Align with the Company Culture or Choose to Intentionally Break it

A several years ago I was part of a company servicing the Higher Education Industry that changed its operating model and I can say it was a less than fun experience. The company moved from a diversification model to a replication model in order to address what was a changing industry. Deregulation has removed barriers to entry and new competition was driving down both sales and margins. Additionally, the workforce was aging and as employees retired their institution knowledge and connections were lost.

In the past, team members would spend 30 years working for this company because each location was given significant freedom to cater to their unique market and the bonus structure was configured to significantly reward that knowledge and hard work. Inventories and purchasing were managed locally as each market was unique and the people who were in that market knew it best. Only HR and payroll were housed at the corporate office in the Midwest and most other IT decisions were made by the local management.

When the industry was deregulated, these colleges and universities had to publish what had previously not fallen under the Freedom of Information Act. The moved the power from the seller to the buyer and increased competition. In efforts to keep pace with the changed landscape the President of the division I worked for began the shift to a replication model. Purchasing, Marketing, inventory management and other core aspects of the business were one moved to corporate control out of company headquarters. In theory this was a solid business move as it would allow for standardization and replication across the several hundred locations. However, what occurred was a dilution of the culture and uniqueness of each location.  Every college and university has a different look and feel and that was translated by the local staff into sales. Those at the HQ office had no idea what each location was like nor had they ever visited most of the schools. Local managers could make suggestions but actually getting something approved took so long the business opportunity was often gone by that time. Additionally local vendors who had been doing business locations for decades were shut out because central purchasing was not willing to purchase for just one location and these local products were what sold well. Central purchasing ordered standard items from national vendors and the local stores lost their identity.

After a couple of years sales continued to decline and management placed the blame at the local level. They stated we were not executing the plan and we stated the products they provided were trash. It wrecked the existing company culture, caused many experienced team members to move on, and it took a couple of years for the new operating model to establish itself. That said, this shift in operating model did allow the company to sell off this business unit several years later even though the industry was in continued upheaval. It could be described as successful depending on the viewpoint one takes.

So as one thinks about changing an operating model consider this:

How will you mitigate the short term turbulence so you can best get to the long term gain an operating model shift can provide?

Don’t throw the baby out with the bathwater. 

LOB Managers can be the key to EA

Generating support for EA in a federated organization can be a slow and difficult process. Line of business owners often wish to maintain autonomy and power to make decisions that benefit their local needs because they are the ones “getting work done”. Their support for EA initiatives is critical as a gateway to their constituencies. Most companies by now have an EA program which has been mandated and is supported by upper level management as they work to realize the full value of their IT investments. These local line of business managers are the ones who if listened to, can help drive the business process automation,  and efficiency that EA seeks. This is because they understand how the information they have, and their daily tasks interface with other points in the organization. Communication (great and poor) is very often the culprit of process loss as the understanding of each groups “needs” and “nice to have’s” may not be a 1; 1 match. Much of the value EA can provide is directly related to the translation and standardization (to whatever degree possible) of that information.

So why does this process happen poorly so often?

People see what they want to see and hear what they want to hear. Every individual has a unique viewpoint through which they approach change and to many it change inspires fear. Setting a  groundwork of openness, a culture of transparency and an atmosphere of trust is critical to the success of an EA initiative. This means gaining their trust so the EA team can gain the deep experiential knowledge line of business manager have as they functionally meet day-to-day business challenges. We all know that executive support for EA is critical but a 37,000 foot view of an organization will not fully optimize the value of EA. Actually solving the daily problems faced by the majority of the organization will give the most time back to those employees. The questions should be asked:

What do I want my employees doing?

How do I want them spending their time?

Does this task actually add value to the organization?

Automate the administrative tasks so people can spend their time on what actually matters: Your customers. 

BLOG # 1 - IT Tools and the Customer Experience

As I reflect on the reading this week I can’t help but think about the magnitude and scope of an EA program in most organizations and how to make them agile enough to respond to ever-changing business needs of a firm. This led me to the low hanging fruit – “Make your Enterprise Architecture flexible also”. However, this is easier said than done. As many organizations look for more effective ways to structure themselves around the customer experience the IT systems and governance must adapt. We live in the world of 1 hour Amazon delivery and manufacture on demand that have changes customer expectations. An organization that provides a poor customer experience will never stay on top of a business. This means setting EA cycles not just more often but with the “Just Enough, Just In Time” mentality described by Allegga in “Enterprise Architecture: “Just Enough, Just in Time”.

This (re)new(ed) customer focus demands no silos and a singular customer facing voice that is a contrast to how most organizations are structured. Even in matrix and project based organizations silos can develop as different teams adopt different tools to meet the daily needs. However now with the expectation of “no boundaries” companies are tending to tear down these traditional silos and this means IT tools need to be more flexible as they reach greater constituencies and also more scalable to each constituencies size. This is why it is critical to socialize EA and make sure the communication component is robust.

In my experience implementing new IT applications can be distasteful to the end user and management as learning a new system often reduces production in the near term. To me, early and frequent communication is not only the most effective but also an inexpensive solution ignored by project teams. This also involves taking the time to listen to those same end users and not just upper level management. To me that is the core challenge of EA – How do we identify the best solutions for the enterprise with many competing viewpoints?

 What would our ideal tools look like in the future-state, where we organize ourselves in a way that is focused solely on our customers?