SAAS and a tropical vacation- Their surprising similarities

SAAS and a tropical vacation

SAAS-Like a trip to the beach without the travel headaches

Over the past few years Software as a Service (SAAS) and cloud offerings have become more and more prevalent in our recommendations to our clients, particularly when clients are coming to us to help them look for cost savings. In both the public and private sector cost has become the single most cited reason for clients requesting our services.  However for clients, particularly those coming to us from the “business” side of the house as opposed to the technology side of the house, there is something especially scary about capabilities that reside “off-site.” I think for many people there is comfort in knowing that they own the hardware, software, and even the building in which their capability resides. To my mind, this is representative of old-world thinking that simply won’t be sustainable as we move forward. The economics of multi-tenancy “where a single instance of the software runs on a server, serving multiple client organizations (tenants),[1]” is simply too powerful to be ignored for long. I’ve told clients that it’s like taking a vacation to Jamaica without having to endure the travel time. You get the same results. You end up in a nice sunny, warm place with great beaches—but you get to avoid the travel time, skip the long lines and bypass the cramped seats. SAAS and cloud offerings give you all of the benefit minus many of the headaches. You don’t have to procure and manage the hardware/software, in fact you avoid most of the “other” distractions and costs that come along with owning your software capabilities.

Of course you don’t really avoid the costs, they are simply bundled into the solution you are receiving. Ideally this is happening in a manner that enables the vendor to take advantage of large economies of scale resulting in better performance at the same or a lessor price point. Of course it isn’t all benefit. It does require some reskilling for IT professionals in order to enable your organization to get maximum value. You need to be able to “shift from delivering IT solutions to brokering business capabilities.[2]” You also need to be able to understand the security, data implications, access and other factors that will affect your corporate data. This area deserves a much richer treatment than I can give in this blog post but for those interested a great place to start is with the recent MIT Center for Information Systems Research (CISR) paper “Embrace the Inevitable: Six Imperatives to Prepare Your Company for Cloud Computingby Mooney, Ross and Phipps. For the purposes of this post, suffice it to say that the concerns most people have center around security, access to data, and flexibility. These are all real concerns, which is why you still need great technologists available within the organization in order to help you develop solutions that meet your specific business requirements. However, I will say that sometimes these concerns are overhyped.

I will use security as my example. I believe that with many SAAS and cloud vendors capability in this area probably far exceeds what you may currently have in house simply because the impact of a breech would have such negative consequences. Salesforce CEO Benioff talks about the importance of security to his offering because companies like Dell and Cisco are putting some of their most important data, their customer data into the solution. The ripple effect of a loss of confidence in their security model would have enormous ramifications for the business. Therefore they are incredibly focused on delivering in a secure fashion. I personally find it hard to believe that given the combination of the reduction of the importance of security to the business model and the more standardized technology architecture that SAAS and cloud vendors don’t have an easier time securing their solutions. Think about it like this—the Department of Agriculture has more than 700 applications all with different architectures. How much more difficult is this to secure than a SAAS vendor with 700 clients all using the same application on a standard architecture and with an overriding business imperative to be secure or risk losing all of those clients in rapid fashion. I’m not saying the SAAS vendor will be more secure, I just think the design forces favor them. What do you think? Most of us have gotten used to the SAAS service delivery model in our personal lives and transact business and interact via social media using these services everyday. Are you ready to make the leap to take your organization there?


[1] http://en.wikipedia.org/wiki/Multitenancy

[2] Embrace the Inevitable: Six Imperatives to Prepare Your Company for Cloud Computing, Mooney (2012)

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at events@joshmillsapps.com.

If you are interested in consulting services please go to MB&A Online to learn more.

It all starts with the operating model

It all starts with the operating model, at least that is my belief. Since reading Enterprise Architecture As Strategy: Creating a Foundation for Business Execution by Jeanne W. Ross, Peter Weill and David Robertson I have really focused on understanding one of the foundational statements early in the text regarding the role of the operating model which includes, “The degree to which successful businesses must standardize business processes and/or integrate data to produce optimized business outcomes.” Viewed as a four square chart, this produces a range of possible states for the organization along these two lines as shown below:

It all starts with the opearting model

Loosely grouped these essentially can be defined as follows:

  • Diversification model: low standardization, low integration
  • Coordination model: low standardization, high integration
  • Replication model: high standardization, low integration
  • Unification model: high standardization, high integration

One of the reasons why this is so important in the process of understanding how you should be looking at your organization is that it keeps you from falling into the trap of thinking that more standardized and more integrated is always good. I have heard many, many very smart and well-respected executives talk about EA as though the entire point of it was to develop a consistent mechanism for becoming more standardized and integrated. This overly simplistic viewpoint can be a value killer for many organizations. The fact is that there are numerous reasons to opt for less standardization and integration. I am going to focus on those in this post because the case for standardization and integration is so stunningly obvious and uncontested.

Specifically, process orientation and integration is the enemy of agility. I know that by saying this I will have people tell me that I just haven’t seen it implemented correctly. This misses the point. The fact that you have a standard way of doing something means almost by default that the person engaged in the process does not generally have the full freedom to do the process however they see fit. Hence, it is less agile. I’m not going to debate whether or not you can have an agile, standards-based set of processes—I’m sure you can. I’m just saying they aren’t as agile as no process almost by definition. The real world situations where less process may be good are many but may not be obvious, so I’ll share a few examples.

The first is an organization that is rapidly acquiring other organizations or has a heavy focus on M&A activity. These organizations are probably better suited to focus on less process orientation and integration, as the process of moving acquired organizations onto a specific set of processes and ensuring a tight integration of data will necessarily slow the acquisition process and may slow the time to a return on investment. If this organization is a highly diversified conglomerate, it may be that its business and technology executives should be focused on the diversification model.

 The second is the organization that leverages internal competition as part of its business strategy. An example may be a real estate office where there is fairly heavy process orientation, but less of a focus on integration. The reason is quite simple. The law demands that transactions be processed a certain way.  However, due to how many of the industry’s largest players are organized with individual agents vying for business against both their own organization and other organizations, most of these organizations do not place a heavy emphasis on internal data sharing because it works against this competitive dynamic. The technology and business leaders in this type of organization might want to focus on a replication model as opposed to the unification model.

For the third I think I’ll veer away from the private sector and provide a public sector example. Many public sector organizations, particularly at the cabinet level have very diversified missions. If one were to look at the Department of Agriculture closely, you will find a highly diverse set of missions served by its agencies including banking and financial, emergency response, natural resource management, etc. spread across 150,000 employees. This level of complexity almost invariably means that process standardization across these agencies (business units) will be exceptionally difficult. However, the nature of government and the impact of recent legislation is that the central organization must able to understand and share data across these units. Therefore a focus by the business and technology executives on data integration and standardization is appropriate.  Many public sector organizations, particularly at the cabinet level, would be well served to look at the Coordination model and see if it wouldn’t provide a more relevant scope for EA efforts.

No matter where your organization falls in this, it is important simply to have the conversation across your business and technology stakeholders. Having run operating model workshops with clients it amazes me how divergent the viewpoints can be within just the technology organization or within just the business, let alone across both groups. A lot of the power of the operating model can be gained simply by having the conversation.  There is enormous untapped value in understanding how your organizations operating model can drive how you do strategic planning and technology implementation. Simply asking these types of questions with all of the relevant stakeholders in the room will drive incredibly valuable conversation across the organization. Has your organization had the operating model discussion?

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at events@joshmillsapps.com.

If you are interested in consulting services please go to MB&A Online to learn more.

What is Enterprise Intelligence?

What is Enterprise Inteligencwe

Enterprise Intelligence is a key structure for supporting successful transformation efforts

 In my post “Enterprise Architecture and the Road to Enterprise Intelligence, I talk about an approach to enterprise architecture that results in Enterprise Intelligence.  Wikipedia’s definition of Enterprise Architecture as “the process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key requirements, principles, and models that describe the enterprise’s future state and enable its evolution,” is probably close enough for most. I’m sure that every Enterprise Architect would tweak this sentence or refer me to the TOGAF, DODAF, etc. definition that is more meaningful to them. For this conversation it is good enough because it hits what I believe are the keys to understanding EA, which is that it is about managing change in the service of meeting the vision and strategy of the business.

 This is important because these are the same keys that make it so relevant to organizational transformation. The trend in the world is towards more change, happening faster. Business models are becoming more complex and high performing organizations have to be able to manage change in order to be successful. The period between the instantiation of business vision and the implementation has to shrink. I have honed in on the term organizational transformation because the “transformation” part is a key element. When business vision changes in order to be successful, high performing organizations must be able to change down to the last layer of the organization in order to be efficient and effective. This means changing everything from business process, to application, to performance measurement. Not only must the change permeate every aspect of the business, but it must also be understood that during, and most importantly after, the change that the entire stakeholder community will be affected as well. Enterprise architecture should obviously play a key role in developing this capability.

To me, enterprise intelligence is the decision support structure that underlies both Enterprise Architecture and Organizational Transformation. It is the explicit understanding and management of the key decisions needed to support the business throughout the execution of organizational transformation and its enterprise architecture. Many will argue that understanding the stakeholder community is already embedded in EA methodologies and they would be correct. I’m simply stating that understanding the stakeholder landscape, the decisions associated with this landscape, and the explicit value of these decisions is so important that it deserves specific focus. I’ve talked in some detail about this in “Specifications for Decisions Support” and “The Value Landscape.” Essentially, I believe that enterprise intelligence should provide a framework for understanding the key decisions that impact the organization and provide a framework for understanding the value that these decisions provide. For Enterprise Architecture and Organizational Transformation this should provide the organization with an explicit understanding of the value of undertaking these types of initiatives, while at the same time providing a series of reports, dashboards, and other analytic components and processes that specify exactly how these add value to the organization. Is enterprise intelligence a discrete concrete that should live separately from enterprise architecture?  There will be plenty of opinion on that subject and EAs being the types of folks they are, will make sure I’ll hear quite a bit about it. For me the distinction isn’t for the EAs, it is to help business stakeholders understand the tangible values of the pursuit of enterprise architecture and to tie together the pursuit of enterprise architecture and a capability around organizational transformation.

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at events@joshmillsapps.com.

If you are interested in consulting services please go to MB&A Online to learn more.

3 Reasons the Business Doesn’t Invite Technology to the Planning Table

Senior executives in any organization are always on the lookout for improvement opportunities and re-organizations; value chain re-engineering efforts and large-scale transformation efforts are routinely talked about and actively considered by senior management. Often these changes have enormous repercussions for the IT organization, yet it is often only after much of the path has been set forward that senior leadership within the IT organization is consulted and from there…perhaps the Enterprise Architecture organization. This is despite years of council by practitioners that EA needs “executive buy-in” and endless literature regarding how this is best practice. Why then is it that senior executives continue to engage strategic planning organizations that have no connection to the architecture, or engage in these types of high level organizational re-organizations without EA and the technology organization?
Is technology disconnected from the business?
I don’t pretend that the issues below represent a comprehensive list, but I do believe that below I have listed three of the most common reasons technology and business people are disconnected:
  1. Is that IDEF0?: One sneaking suspicion I have is because they aren’t used to EA or technology being relevant to their decision-making. I think it is pretty clear to most people even at the highest and most “businessy” levels of most organizations that IT is a critical component of meeting strategic objectives and most executives routinely approve IT budgets that comprise a fairly large swath of organizational resources, which also validates the importance of IT. Why then is it an afterthought in the planning process? I think if technology was a bit more proactive in creating views of the organization that as relevant to the business planning process as it does for the technology planning process this wouldn’t be a problem.
  2. Did you just say gigawatt?: Another thought I have is that it may be difficult to bring into the discussion. Many executives have experienced death by IT PowerPoint where a technology executive finally gets his chance to stand with the big boys and polishes up a 75 slide powerpoint deck that ties the strategy all the way down to the servers. This is generally enough to prevent a second invite and executives go back to making decisions with the other adults and then handing it off to the technology organization for action. Speak the language of business and you will get much farther.
  3. My computer already works why do I need you here: Finally, there is the idea that technology is really just an enablement function for the business and therefore strategy should be settled and it is then technology’s job to implement the strategy. I think this is less prevalent than in years past but it is still out there despite the fact that technology has begun to play an important role in almost every aspect of even the most traditional of organizations.
If any of the above sound familiar you may need to start working harder to become more relevant. Successful organizations need IT and the business to work together to be both efficient and effective. What strategies do you do to bring your technology organization in synch with the business?

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at events@joshmillsapps.com.

If you are interested in consulting services please go to MB&A Online to learn more.

Jumpstart or Re-boot your Enterprise Architecture Program

jump!

There is a consensus that technology will play a large role in an organization’s success in the coming years. Technology has seeped into almost every aspect of the organizational value chain and, in many cases, directly supports competitive advantage. From the manufacturing floor, to planning, to marketing, to finance, every aspect of the organization is touched by technology in a way that is quite different than it was just a few years ago. Moore’s law, and the inevitable gains in processing power, is a tangible benchmark that can easily be measured, but innovation and the network of ideas, people, and technology that have arisen in the past 30 years have made an organization’s ability to benefit by leveraging technology to the benefit of the organization a critical differentiator. Underneath all of the much-hyped methods whether it is a shift in computing to the cloud or using enterprise architecture to increase the efficiency and effectiveness of leveraging technology, executives need to buy in, clearly communicate the value they intend to gain, and focus on execution to realize that value. In this article, I will focus on starting or rebooting an enterprise architecture effort, which has been touted by many as the means to align technology with business and ensure the realization of value from technology investments. Unfortunately, many of these efforts have failed to produce the returns that were promised.  In the following entry I will detail how to avoid common pitfalls and make your EA a success.

Building a successful EA program requires organizational credibility and that is why executives charged with developing an EA program should first think of their program as a project. This pulls the focus of the program in closer. Looking more than a year into the future is too long, I know this sounds drastic because EA folks are supposed to be more strategic than tactical, but I think most efforts fail to deliver strategic value fail because they don’t have any of the organizational credibility that is developed by delivering a measurable return on investment in the near term. I want to stress that this isn’t a recipe for every organization; this advice is targeted at those that are trying to start a program or reboot one that hasn’t been delivering. Every program needs to find a path to credibility in order to deliver value in the long term. Using the project approach allows you to become credible now so that you are seen as a responsible steward later. This solves the chicken and egg problem facing so many organizations when it comes to EA because the program needs buy in before it can show results.  Taking a project-oriented approach that delivers value over the course of a year gives proves to the organization that you can deliver results. A program-oriented approach subtly changes the focus of the effort to building the organization and the expanding role of the transformation rather than forcing the focus to stay squarely on delivering initial value. Stay focused on near term value.  Once the concept is proven and a return on investment is shown many of the things that are often discussed, as critical to an EA programs success, such as executive buy in will no longer be a problem because the numbers will be there to support it.

So if you treat your EA program like a project – where should you start? For an EA program I think near term success requires a laser like focus on three key things:
•Problem Definition & Scoping
•Skill Development and Problem Solving
•Executing on the Path to Value

Problem Definition & Scoping

Lack of scope is one thing that destroys the value of an EA program.  Enterprise architecture means the whole enterprise, but most EA programs either end up with a mile wide EA that is an inch thick or pockets of detail that don’t provide enterprise value. Sometimes the dogmatic adherence to a particular methodology derails the path to value because the enterprise architects are working from someone else’s recipe for EA success. I believe that an EA should identify an enterprise problem and help solve it as a project, which will help develop credibility and if done correctly, should provide a pillar on which the greater success of the EA program can be built. Critical factors to consider are the probability of success, access to information, and potential value to the organization. Do NOT forget the probability of success; great intentions and great potential won’t get you anywhere unless you can pull off the win. You absolutely must be able to develop a problem statement that will be universally accepted and that will define what success looks like. You can take on harder to measure, more strategic problems next year. A first great project starts with your organization’s application portfolio, unless your organization already has a good handle on it.  This is an ideal place to start because it is an area in which an EA team can bring exceptional short-term value while building a resource for the organization that will provide long-term value while building a resource for the organization that will also provide long-term value. Done correctly this should help you develop a high level understanding of the capabilities required to execute the business of the organization, a complete application list in the context of those capabilities, and an understanding of the technology components that comprise the applications. In most organizations I’ve seen the results of this analysis is fairly stunning, since redundancy and opportunities for consolidation become almost immediately apparent.

Skill Development and Problem Solving

Once you have defined your challenge, you will need to make sure you have the appropriate skills in order to accomplish the tasking. Even in the application portfolio example discussed above, you often need to develop specific skills with regard to tooling and taxonomies. Scoping down the work required to develop a full blown EA program into a specific effort to develop organizational value may also bring into focus the need for critical training around specific areas of effort that may dictate project success. However, if you want to fold these informational inputs into a larger EA framework you will need to begin closing any skills gap your team has with regard to understanding the bigger picture of what EA can and should be delivering. Most EAs come from solution architect, or other more specific architectural or technology oriented disciplines. Training on big picture EA concepts as well as meeting specific skill gaps, is critical during the execution of the project phase so that your project oriented EA effort doesn’t become another stove-piped information set. Even though you will have scoped your effort as a project it is critical to keep in mind that this is a step towards solving larger and more strategic issues facing the organization. Training around EA concepts and other more general skill sets is critical in order to keep the big picture in mind as you work to solve a more narrowly scoped organizational issue.

Finally, you may also want to address general productivity and problem solving. Is your team able to deal with communication challenges, leadership issues, and collaboration or organizational productivity concerns? Figuring out how to work together effectively can be as big a challenge as figuring out how to solve a particular problem. I find that EA teams that are broken down by EA functions like security architecture, information architecture, and business architecture can sometimes become their own stovepipes. Using a project-based approach solves the stovepipe issue because it forces staff to work together to develop organizational value. Too often EA programs that are focused on building a program have individual architects working to build “their” architecture rather than a shared architecture that is understood across all domains. If your team is struggling to work together, consider addressing productivity, teamwork and collaboration skills specifically outside of the technical skills required to implement the EA project. Sometimes the type of detail oriented, high intelligence individuals who are able to understand and develop EA concepts require help in the area of soft skills.  I cannot stress enough how important this area will be to creating real organizational value. Enterprise architecture will always involve relationship-building skills in order to be successful because you are dependent on others to gather and use information. Don’t become so focused on technical development that you lose track of the soft skills required to solve real organizational problems.

Executing on the Path to Value

Once you’ve identified a manageable scope, sold the idea to management, developed success metrics and identified skill gaps it is time to execute. During execution, it is very important to stay on schedule and ensure that your project does not become a victim of scope creep. Many of the inputs into even something as simple as the application portfolio effort mentioned above can easily become the victim of a lack of access to outside resources. A critical factor in meeting your goals is staying on top of the execution and schedule and leveraging your executives in order to get the information you need to be successful.  Make a project plan. You cannot manage your EA program like a project without identifying key milestones and marrying them to a realistic timeline. Keeping a tight rein on that timeline and ensuring that you manage the effort in order to meet these evaluation gates is critical. If you begin to fall behind or encounter organizational roadblocks or unanticipated challenges it is imperative that you react in real time. EA programs are often derailed by the combination of scope creep and a perceived lack of value. If you begin to slip on schedule ask yourself why. The answer is almost always a skill gap, scope creep or lack of access to informational resources. The latter is probably the hardest to deal with but if you have defined the project well and scoped it with an eye towards organizational value you should be able to make the case to an executive who will help support your access to other organizational resources. If you find yourself with a skills gap or scope creep, you may want to consider leveraging outside resources to bootstrap yourself into your initial success. Having a seasoned EA or tools specialist that can help address technical issues can be critical to the success of the effort at large.  Having outside support can also help guard against scope creep by enabling a respected outsider to weigh in on the implications of specific items that may fall outside of scope and, therefore, either increase the time to value or add little value.

In fact if you are rebooting or starting an effort from scratch it is very likely that you will need some level of outside assistance in order to meet your requirements. The type of assistance is likely going to be dictated by the skills gaps you have previously identified, and most new teams will require some type of outside assistance as they execute. Areas to think about in advance are tooling, general EA competency, productivity and mentoring. I think the first few are self-explanatory but I would like to expand on the idea of mentorship and introduce the idea and importance that workshops can have on enabling real results. I am a big believer in training and many of our folks hold multiple certifications in addition to advanced degrees. However too often this training is under utilized because of the gap between learning new skills and using those skills. Mentoring can help bridge that gap as well as provide the type of expert advice and experience that will prevent costly missteps and ensure that you meet your success criteria. The right mentor may also enable you to better communicate value upstream by virtue of their ability to communicate current efforts in the context of their own experiences. Having someone who has lived the project you are now executing keeps missteps to a minimum and ensures the path to value is fairly straight. Workshops are another great way of leveraging the experience of experts in the context of your own projects. In our application portfolio example it may be useful to run a workshop around the evaluation of a application portfolio that provides both training value in terms of developing an understanding of how to evaluate the portfolio as well as real value by performing those very tasks using your organizations real data. I believe this type of combined learning is invaluable in terms of building near term value and long-term skill development.

Conclusion

Your ability to jumpstart or re-boot your EA program depends on defining project level objectives, building the right skills, and staying on top of execution. The eventual goal of most EA programs is to truly transform the organization in order to support agility, efficiency, and effectiveness in a manner that delivers a sustainable competitive advantage by achieving a more perfect relationship between technology and the business. It is by its very nature a complex and difficult endeavor. In fact most organizations have been unable to get to the value they hoped for from these types of programs and projects. The fact that so many organizations continue to support these efforts is a testament to the benefit the organization will achieve if it is successful. Executives intuitively understand how beneficial this type of program could be, but, they often lack a proven means to achieve this value. I suggest focusing on scoping a project level EA first because it removes some of the complexity from the program and defines it in manner that can be understood by the business. In the application portfolio example, the business case is centered on removing cost and increasing efficiency in the application portfolio. Once complete this EA project will have developed a very strong informational backbone on which you can hang other program level EA inputs, provided a return on investment back to the business and established organizational credibility. This is the foundation on which other more strategic efforts that may have harder to measure outcomes can be placed. I believe that even EA programs that have a history of success should always evaluate their program portfolio to ensure that there is a mix of projects that deliver short and long term value in order to ensure that they stay relevant to the organization as a whole. Your EA program should never have to hunt for organizational or executive buy-in. If it is done correctly it should become a driving force within the organization that ensures the efficient and effective application of technology in order to improve performance. Getting there will require your team grow their skills, keep their focus and build relationships across the organization.

Put our team to work improving your organization’s performance.
Visit Millsapps, Ballinger & Associates online.

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at events@joshmillsapps.com.

If you are interested in consulting services please go to MB&A Online to learn more.

Enterprise Architecture and the Road to Enterprise Intelligence

Executives and managers are always looking for ways to increase organizational performance with regard to the effectiveness (How well am I achieving the mission?) and efficiency (Have I optimized my approach to achieving the mission?). In the course of trying to get there they have looked at many different disciplines and approaches including Enterprise Architecture. Enterprise Architecture is an alluring approach because the logic is solid; by understanding the blueprint of the organization from the context of the business architecture, data architecture, etc., you gain a deep understanding of organizational inter-relationships. This will identify the ripple effect of actions, and enable complex analysis thereby unlocking new levels of organizational performance.
Understanding Complex Relationships to Help Deliver Value
Not only should executives be able to use this body of knowledge to support a multitude of decisions, but the execution of the discipline should create a virtuous cycle whereby, better information, leads to better decision making, which leads to better processes and so on. The organization as a whole should become inherently more agile by virtue of its understanding of itself. Unfortunately, for most organizations it has been very hard to close the distance between reality and this vision of the future state. Many organizations have continued to soldier on in search of this promised to-be state because the logic behind the concept is so powerful and the return on investment, if the organization is able to achieve even a hint of the promise, is so great.
The discipline as a whole has been plagued by this reputation of over promising and under delivering almost from its inception. I think that this stems in no small part from the grand scale of the undertaking as it is often envisioned and then methodically trudged towards. Other contributing factors include the dogmatic adherence to specific methodologies and processes as well as a tendency on the part of the practitioners to over emphasize the exercise over the end state. I think this last part, the end state is the where the real disconnect occurs. The problem is that for executives and the managers, the desired end state is a higher performing organization because of the impact of getting the right information, at the right time, to make the right decision.  Unfortunately, the desired end state of the architecture program to often appears to be a complete architecture, adherence to architectural process, the evolution of architectural process and/or the perfection of the PowerPoint presentation. I have no doubt that there is real virtue in the application of many of those concepts and capabilities in order to achieve real and lasting value from your Enterprise Architecture, however I think that it is important to first start by ensuring that your organization is approaching Enterprise Architecture as a means to achieve Enterprise Intelligence.
What is Enterprise Intelligence? Enterprise Intelligence is the decision making capability that enterprise architecture should be leading you to deliver to your stakeholders. Executives, managers and other stakeholders should be able to intelligently query an organizational service that can provide answers to questions that lead to greater efficiency and effectiveness like:

  • Are we efficiently purchasing software/hardware in order to deliver organizational capabilities?
  • How are the services we provide externally and internally performing?
  • How does information flow within the organization?
  • How are the services that we provide supported with regard to resources (IT/HR/Physical Assets)?
Develop Resources that Enable Stakeholders to Improve Performance
Most importantly the questions and answers need to resonate with your organization. It is critical that the outcomes of the processes and activities you perform be things that your stakeholders will use. One of the great failures of many Enterprise Architecture efforts is the failure to make this connection to service provision. It is absolutely critical that your end users be engaged and that your products are used in the decision making process. Otherwise, someone will inevitably come around to question why the effort is being undertaken at all. Nothing, I’ve said above should come as a surprise to anyone who has been engaged in these efforts for any length of time. The temptation to refine the HOW of the EA program is simply too great, and an entire industry of software products, methodologies and consulting services have grown up around it. However ignoring the WHY, is in my opinion, the single greatest cause of the failure of EA to live up to its promise. EA programs need to be run as a service organization to succeed and a major part of that is focusing on the customer experience. The EA team must be in the business of providing UNIQUE insight into the organization, and they must show that they value and are responsive to their customers. That is in large part to say that the value EA provides should be in linking together information in disparate systems within the organization. Tying it to some context provided by the EA organization and making that combined information available to executives and managers in a way that facilitates decision making, prompts further investigation and provides feedback on performance.

Getting from Information to Outcomes Requires Unique Insight
How do you do that? I think understanding the process required to deliver on that promise within a particular organization can only be done by starting from the stakeholders and working backwards in the process for deriving it. I am not saying their is no place for best practice and methodology, but I think an organization is better suited to make a determination on methodology by starting from an evaluation of the decisions it does make (and should make) first. Do not forget the “should” in the last sentence, one of the things that EA as a discipline has gotten better at is in providing examples of reports and artifacts that can be used to support different aspects of the architecture. Some of these are quite useful and one of the real benefits of the extensive promulgation of best practice and methodology-related documentation within the discipline has been the ever increasing number of example reports, dashboards, models and analytic artifacts that are available online. Looking at what others have developed as an end state should help you and your stakeholders identify things that you could use for your own purposes. This is also an area where looking at the various tools on the market can be of assistance as well. Tool vendors often have some unique insight and experience by virtue of working with many programs in a relatively compressed time period, however it should be noted that this can also be a limitation because their job success in large part is predicated on how well they are able to get the software in the door; not on the long term success of the program.  Obviously, real success for these companies comes when their clients succeed, so they will be motivated to position your team to succeed, especially in the run up to the sale.
Without diverting this discussion into an extensive look at EA tooling, I think one of the things that must be recognized is that tooling choices are important because of the way in which they can accelerate the path to value for a program. This will enable the mangement of this complex organizational decision support tool, and enable the type of ongoing analysis and reporting that drives the customer’s experience of EA products. If your tooling is only available to a select stakeholder community you will need to ensure that the value of your teams work makes it into the hands of your customers (executives, managers, etc). If the tooling interface is too complex or if the tool cannot be configured to sustain high data quality, again your stakeholders will suffer.
The tooling should also enable your program to combat another EA program killer, which is stale data. A real Enterprise Intelligence capability requires that the data being analyzed be correct. The user (customer) community will need only find stale data a few times before deciding to get information from other sources. For the architects developing this informational service, it is critical to understand where information comes from, the process that creates it (manual, automated, etc), the refresh requirement in order to maintain accuracy, and the precision/accuracy of the data. This enables the team to provide stakeholders an explicit understanding of the level of confidence they should have in the information they are using to make decisions. One of the issues I often see in the use of EA information to support decision making is the hesitancy of stakeholder to use data to underpin important decisions because the EA team has failed to provide a mechanism for the user community to gain confidence in the information. One thing that programs should do in order to ensure customer trust is to make sure that they have made it easy for stakeholders to develop confidence by providing clear labels, open discussion of informational flows and appropriate messaging during training sessions and service desk calls.

Establish a Clear Line of Site from Inputs to Reporting
Additionally, achieving the benefits of Enterprise Intelligence requires a real focus on strategic communications, training and support. Far too often the focus of an EA effort is on process and content, and while I agree that without these your EA program will certainly fail, these alone are not enough to sustain a program. The stakeholder community cannot leverage any of your good work without an understanding of what information is available, how to access it and an understanding of who to call in order to ensure they get value from it. The point has been made often with regard to the corporate use of big data, analytics, and statistical information that these capabilities often under deliver on their promised return of investment because of a lack of organizational readiness to leverage them. The same is true for Enterprise Architecture. A commitment must be made on behalf of the program to not just develop the information and processes needed to succeed, but to mentor those that are supposed to be receiving value from them and how to get that value. A successful EA program invariably includes someone that is focused on strategic communications and marketing in order to ensure that the organization is aware of the value available from the program. This messaging is further developed and enhanced by ensuring that training is available across the stakeholder spectrum. Too often these types of programs inappropriately skew towards a “Let me tell you about how to do EA” approach. This is not productive for those whose job it is to use EA products to get organizational value. I recommend that one starts the process by understanding the stakeholder community and their individual use cases for EA. Then develop a training curriculum that specifically helps them  get the results they need from EA. Another approach is to stack training in order to meet specific organizational transformation objectives. For example, the success of a particular program may be enhanced by ensuring that training is available to help architects understand how to better use a specific tool that will be used to meet an objective, this may be followed by a workshop to meld training with organization specific content to drive a specific outcome while building skills. This may also be combined with executive brown bags that ensure that the people who need to use the information that is being developed are ready to leverage it for the greater good of the organization when it becomes available. In this way, great training programs not only increase the ability of the organization to achieve performance targets, but they also serve as another outlet for strategic communications.
Remember that Different Stakeholders Need Different Training
Finally, great EA programs make sure they deliver a top notch service experience for their customers including making sure someone is there to pick up the phone and support the user community. When you think about the dollars that have been invested to get the right information, in the hands of the right people, so they can make the right decision it is critical that the program is there to support its customers in getting the best value. So often I find that executives and mangers have essentially opted out of their EA programs because “It’s too hard to get real information” or because “I don’t know where to start.” Even after you have done the training, held your “Lunch and Learns” and provided workshops you still need to be there when your customer needs help. Every support or service request is a critical opportunity for the EA program to shine. I highly recommend that a  single e-mail address for support be used, and have a single phone number for people to call. It goes without saying that this service needs to be RESPONSIVE.  Being a part of a business or mission success is the start of an ongoing relationship that will sustain the EA organization in lean times and ensure that there are vocal champions outside the EA organization. That’s it. This is all you need to succeed in turning your Enterprise Architecture program into an Enterprise Intelligence program, and winning the hearts and minds of your customers.

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at events@joshmillsapps.com.

If you are interested in consulting services please go to MB&A Online to learn more.

FedBlueprint: Informational Domains and Reporting for Federal EAs

When enterprise architects examine the information required to plan, organize, lead, and manage their EA, the information set is a bit different from that required by the private sector. These questions are just a bit different than those that would engage a private sector organization’s leadership, partly because of the unique nature of the business of the federal government. Of course, part of it can be directly tied to specific regulations that require certain information be available to external stakeholders (Congress). By and large however, federal EAs are interested and confronted by the same issues as their private sector counterparts. The same pressures surrounding doing more with less budget, transformational technology and trends (cloud, social, big data), evolving compliance requirements, and operational environments are changing the lives of executives, regardless of their affiliation with private or public sector. One way that I like to look at this core set of information is to break it into six major components or domains as follows:

  • Performance Domain: is about understanding how the organization measures performance. This area does not hold the actual assessments against key performance indicators, but rather is focused on what is being measured and how it is being measured. This domain should enable executives to understand the performance management system that is in place for the organization and enable them to see linkages across all of the component parts that enable enterprise performance. Helps answer these questions:
    • How are we measuring performance across the enterprise?
    • How do my investments align to the performance management strategy (e.g. PRM)?
    • What is being measured via Key Performance Indicators across my organization?
  • Business Domain: includes the information related to the business processes, investments, and organizational structure of the organization. A review of the business domain should enable an executive to understand informal and formal organizational structures, the business processes leveraged by those organizations, and the investments of the organization. Helps answer these questions:
    • How are my investments performing in terms of cost and schedule?
    • What is the likelihood and impact of various risks to the projects in my organization?
    • How do my investments align to strategy?
    • Are my investments being managed properly?
  • Information Domain: includes an understanding of the critical information leveraged by the organization. This domain should enable executives to understand the strategic role of data within the organization.  It should also identify areas of opportunity based on a helping identify the relationship between key business concepts, processes and applications working together in the integrated enterprise. Helps answer these questions:
    • How is the data we’re collecting being categorized?
    • Are my applications implementing proper data exchange models?
    • What data is being exchanged between applications?  
    • What data should be exchanged?
  • Applications & Services Domain: enables executives to understand how technologies and resources are combined to create applications and provide services. This domain provides insight into the combinations of things that create business and organizational value. Helps answer these questions:
    • Are my applications in the appropriate infrastructure?  
    • Do I have all of my major applications in an appropriate location?
    • What applications are running on non-standard technologies?
    • Are there similar applications in the enterprise that I can leverage to generate cost-savings?

  • Assets, Technology & Infrastructure: enables the organization to understand the the critical infrastructure, technology and resources required to provide value. These run the gamut of enterprise value from datacenters and radio towers, to manufacturing plants and forklifts. The granularity of the information required by executives from this domain will vary widely. Helps answer these questions:
    • What will be the impact of migrating technology to different stages of its lifecycle?
    • Do we have an appropriate level of data center  consolidation?
    • How is technology distributed throughout the organization?
  • Security & Risk: enables executives to understand the juxtaposition of risk and security as it pertains to the delivery of value and the ongoing operation of the organization. This area should enable executives to understand how physically secure their assets are in the bricks and mortar world, as well as how secure the informational aspects that support the organization’s value chain are supported as well. Helps answer these questions:
    • How well are we protected against known security threats?
    • How informed is my organization about security best practices?
    • How many security incidents have occurred in the last 30 days?

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at events@joshmillsapps.com.

If you are interested in consulting services please go to MB&A Online to learn more.

Avoiding the common pitfalls of enterprise architecture

The history of enterprise architecture as a management discipline has been marked by failure to live up to the promise it showed as a concept. The idea of an enterprise architecture and the explicit understanding of the relationships between the most critical forces, resources, and processes involved in the execution of  an organization’s business is powerful.  People can grasp on an intuitive level how powerful the reality of that concept would be if it could be put into practice and harnessed on behalf of the enterprise. Unfortunately, the conceptual enterprise architecture that enables the agile enterprise and informs executives in the midst of critical portfolio and execution decisions has given way to a morass of additional bureaucracy and expensive efforts to create enterprise models that are more often significant as records of organizational history than as blueprints for the future. The problems lie in three areas.  The first of which is a lack of clear performance objectives for the EA effort. This early effort to understand what the organization is attempting to achieve through its EA efforts is critical, to the point so that not having this in place almost certainly dooms whatever effort occurs in its absence to failure. It is simply impossible to get value from any effort so potentially broad as an EA effort without determining in advance what success will look like in order to focus the effort around areas where the EA can benefit the organization meta-model as a whole. The second major failure stems from the belief that EA is somehow all about the process for developing content; although it seems that almost 90% of the material you read regarding the discipline is related to eliciting information from the enterprise, modeling the information, or frameworks. I am a big believer in the fact that having the right information is critical to the success of the EA effort by and large, but I know from extensive experience on client sites that too much focus on methods and models leads to a low return on investment for the organization as a whole. Finally, there is far too little attention paid to helping the consumers of EA information. This last one is really simply the end product of the first two, but I have almost never had a project where I felt the funding allocated towards stakeholder communication, marketing, support and documentation was commensurate with the dollars spent to develop the content. In the following sections I will provide a few tips for refocusing your EA effort to avoid these common pitfalls or refocus efforts that have gone astray.

Lack of EA Performance Objectives

Establishing performance objectives is a good idea when it comes to executing any change initiative and EA really should be a major factor in effectively managing organizational change. With that said, EA is also often set up as a program with no defined end date and not particularly tied to any specific initiative within the organization. Where a supply chain management modernization effort may be able to easily show a return on investment and meet key performance indicators regarding cost containment or increased organizational capacity, EA efforts are often not as easily measured on the surface. However, I think that by setting forth both high level measurements that an EA program should influence like ratios of IT spending to operational spending and total cost savings, as well as more internally focused measures like percentage of compliance with EA/IT Governance or Common Services Usage the program sets itself up to be able to meaningfully advocate for itself on the basis of providing value to the organization as a whole. One of the most critical things establishing EA performance objectives does is force the team and sponsoring executives to really hone what they are hoping to gain from their EA efforts. In addition to establishing explicit performance objectives like those mentioned above it provides an opportunity to discuss and align the EA efforts with particular organizational main points like portfolio management, meta data management, or other critical organizational initiatives.

Over Emphasis on EA Content and Process

EA efforts are often said to be focused on the organization’s to-be state. Unfortunately, too many EA efforts spend so much time focusing on the to-be state of the EA effort that they never deliver value to the organization. Successful EA efforts get to business value as rapidly as possible.  That’s not to say that there is not a place for well thought out processes or that thinking about the meta-model isn’t valuable. Simply collecting a bunch of information by any means is not what I am advocating for, what I am trying to advocate against is the endless evaluation and tailoring of methodology, framework and meta model that seems to dog so many EA efforts. Perhaps it is simply in the nature of architects to sweat these details, but leadership needs to temper this desire to rigorously hone the processes and models that will be used to carry out the EA effort with a focus on addressing real business issues. I like to think of every EA effort as having two tracts.  One is the strategic tract where long term organizational value is built via the rigorous application of EA techniques and methodology to managing the enterprise, and the second is the tactical tract that applies the techniques and talents of the EA staff to deliver near term value to the enterprise. I believe that these shorter term objectives, while possibly falling outside the purview of traditional EA, build the organization’s faith in the longer term value of the effort, ensure communication with the business, and guarantee that EA always has an answer when the value question is asked.

Under Emphasis on EA Consumers 

A byproduct of the lack of performance metrics and over emphasis on EA content and process is a lack of focus on the EA consumers. So much attention is paid to the information that needs to be brought in and the process by which to bring it in that the return of this information in usable form to the content consumers is an after thought at best and often simply does not happen. The fact is that the structured models and techniques so often used to elicit information from the enterprise are often not the best mechanisms for returning that information to decision makers. For EA to have a positive impact on organizational performance it is critical that attention be paid to the consumers to this demographic before going out and harvesting the organizations information. Understanding where EA information can play a role in enhancing stakeholder decision making and working in coordination with these stakeholders to develop meaningful information collections in formats designed to support the decision making activity are critical to transitioning the organization to the type of data driven agility that is supposed to be the hallmark of the architectural organization. Working from the decision backwards can be of enormous value in these types of efforts and can help focus EA efforts on informational gaps in the enterprise that can show the value of EA as a discipline in a way that simply focusing on the macro EA effort cannot.

Put our team to work improving your organization’s performance. Visit Millsapps, Ballinger and Associates online.

Thanks as always for reading my blog, I hope you will join the conversation by commenting on this post.

If you liked this post, please consider subscribing to this blog and following me on twitter @jmillsapps. I regularly give talks via webinar and speak at events and other engagements. If you are interested in finding out where to see me next please look at the my events page on this blog. If you would interested in having me speak at your event please contact me at events@joshmillsapps.com.

If you are interested in consulting services please go to MB&A Online to learn more.