Along with Enterprise Architecture coming under increasing scrutiny the role of Enterprise Architects (EA) is having image problems as well. Most CXO’s understand at a high level the function of the role and may even value it but find it difficult to measure or quantify the value in business terms. At a macro level for all of us that challenge is the same.
In my experiences I have found that there are different ways people evolve into the role of an EA. Some come from business backgrounds and process engineering backgrounds or they have a technical background and have been a technical architect at some point in their career. The interesting thing about EA’s is that in my mind the industry has not really had a good definition of what an EA actually is and how they drive value.
To tie this together and provide a broader perspective we need to look at one of the current industry trends in the IT field today. The current trend of IT to business alignment has had resonance for some time now and people are beginning to understand how to bridge the chasm. There is alot of activity around IT to BT (business technology) mapping and how IT can better drive value back to the business function it is supporting. If you have an EA employed who is not driving this value than it is the right role but might be the wrong resource in that role. The role of the EA is usually not as clearly defined as the role of a developer of even CIO at time. It is usually left to the individual who is filling the EA position to define after they have filled the role.
So now that the problem has some more color how do we approach the role of an EA and how will it drive value in the end. The best way to start is as with all good beginnings, partner with your head of Human Resources (HR) and the business executives that will receive the benefit of what this role could bring. Taking this approach and gaining buy in from your peers goes a long way to help in the alignment process. If aligned correctly this role will drive the business to IT alignment and governance models ensuring the partnership remains healthy as the dynamics of the business climate change.
Some of the key attributes that a successful EA should have are typically:
a solid understanding of business models and how P&L works from a business leader perspective
technology agnostic in everyway and hopefully has served in a technical architect capacity
management skills to be able to work well with diverse blended teams
Having an Enterprise Architect on staff is not for the faint of heart for companies that are experiencing significant cost pressures. They are a senior level position that has more of a financial commitment than other positions within the IT function. Along with this having an EA approach to running your enterprise is a costly proposition. Adoption of this approach has typically occurred in the Federal sectors and larger Fortune 1000 enterprises where there is a little more discretionary budget to create the ability to focus on more strategic IT initiatives. This does not imply that this is an elite position reserved for a select few. I have witnessed and consulted with small to mid size organizations that have been successful in having EA’s that are multi-functional. Although this sometimes contradicts some of the primary disciplines of an EA, rules are sometimes meant to be broken. From what I can see that is what has driven innovation in our industry to date…
Thursday, June 12, 2008
Friday, June 6, 2008
To have an Enterprise Architecture (EA) or not?
The topic of Enterprise Architecture (EA) has been coming under scrutiny in recent months as cost pressures continue to drive businesses to look for cost savings through driving efficiencies. If you have experience in large enterprises and have had to deal with the implementation of an EA than you know the complexity and cost of that effort. It is not only the creation of the architecture maps themselves but the staff, modeling tools, business and time commitments it takes to achieve the ROI that an EA is intended to bring. These all in costs can be staggering to an Executive who is really trying to achieve the fundamental goal of understanding the enterprise and how it drives value for the business.
In order to baseline this thought lets first understand that in my humble opinion the fundamentals of EA are good in their intent but are wrought with challenges in execution. Commitments from your business partners are typically very high, the software tools are expensive and the value of an EA diagram is difficult to qualify against the investment.
I believe that John Zachman's EA framework was a significant step forward for technologist who could not see that at the end of the day technology is great but only if it meets the business objective. It brought about a new way of thinking about technology and how to create solutions that drive to a business result measured in less binary terms. Now having been an Enterprise Architect in some very large enterprises both commercially and in the Federal Government I can see the value of an EA but offer a different approach to achieving the value as well as driving the savings through not only efficiencies but automation.
My approach leverages some of the converging technologies such as Business Process Management (BPM), Enterprise Service Bus (ESB) and Service Oriented Architecture (SOA). Instead of creating a diagram that is static and non-actionable I propose that EA's are input into a BPM tool and bring life to the Enterprise through the ESB and is governed by the organizations SOA strategy. This approach allows the technology the business to control the technology in a more transparent manner while increasing the value of the CIO/CTO, IT staff and existing IT investments. Leveraging automation, improved integration and the same business centric approach you can make systems more robust and adoptive to the changing business environment as well as improve agility of the component systems. It becomes easily updated as the business needs evolve and can audit the processes that run through the tools very easily.
Now with that said everything has to have balance. As a technologist it is critical to always have a business, not technology centric view of everything that we do in the new economy. The fundamentals of these approaches are to give us new tools to build from and new challenges to drive innovation. I believe that through this alignment IT can be more of a strategic business partner than in the classic terms that defined it in the past.
In order to baseline this thought lets first understand that in my humble opinion the fundamentals of EA are good in their intent but are wrought with challenges in execution. Commitments from your business partners are typically very high, the software tools are expensive and the value of an EA diagram is difficult to qualify against the investment.
I believe that John Zachman's EA framework was a significant step forward for technologist who could not see that at the end of the day technology is great but only if it meets the business objective. It brought about a new way of thinking about technology and how to create solutions that drive to a business result measured in less binary terms. Now having been an Enterprise Architect in some very large enterprises both commercially and in the Federal Government I can see the value of an EA but offer a different approach to achieving the value as well as driving the savings through not only efficiencies but automation.
My approach leverages some of the converging technologies such as Business Process Management (BPM), Enterprise Service Bus (ESB) and Service Oriented Architecture (SOA). Instead of creating a diagram that is static and non-actionable I propose that EA's are input into a BPM tool and bring life to the Enterprise through the ESB and is governed by the organizations SOA strategy. This approach allows the technology the business to control the technology in a more transparent manner while increasing the value of the CIO/CTO, IT staff and existing IT investments. Leveraging automation, improved integration and the same business centric approach you can make systems more robust and adoptive to the changing business environment as well as improve agility of the component systems. It becomes easily updated as the business needs evolve and can audit the processes that run through the tools very easily.
Now with that said everything has to have balance. As a technologist it is critical to always have a business, not technology centric view of everything that we do in the new economy. The fundamentals of these approaches are to give us new tools to build from and new challenges to drive innovation. I believe that through this alignment IT can be more of a strategic business partner than in the classic terms that defined it in the past.
Monday, March 31, 2008
The Decompossion of SaaS
Software as a service (SaaS) has been creating a buzz for some time in all aspects of the IT industry. With all the differing delivery models, definitions, marketing messages and hype what is the value at the end of the day.
To understand the value it is my perspective that we need to look at how we got here. There is much debate on the history of SaaS and how it was derived. From what we have seen in our industry over the years, the Application Service Provider (ASP) industry paved the way for businesses to explore the concept of off premise software, accessed through the Internet or some sort of secure mechanism connecting their enterprise to their provider. Unfortunately the SaaS acronym is not new and was actually one of the original tag lines for a small company in Annapolis, MD. called USinternetworking who was one of the first pure play ASP providers. The concept has actually been around for about a decade now so what has changed?
Having grown up in the ASP / Outsourcing area of our industry the answer to that question is not complex; its the software that has changed. The move to web based technologies, applications migrating to web architectures and new deployment strategies made it easier than ever to support a SaaS model.
Years ago the strategy was to buy one software package that did it all and we saw the rise of Enterprise Resource Planning (ERP) applications. The strategy was solid in the theory that as a CIO I could standardize my processes, platforms and infrastructure to reduce inefficiencies, how bad could that be? What we found is that unless we truly partnered with the business, identified the right project charter or mission statement, the right business objectives and correct stakeholders these projects were sometimes not successful or ran over budget with ROI models that had diminishing returns.
Taking these high level factors into consideration brings the conversation to SaaS. Web based software, coupled with services and the value proposition is clear when it comes to ROI so what are the drawbacks?
Companies and organizations need to evaluate their application portfolios and contrast them against their security strategies and policies. This analysis will drive the SaaS or not to SaaS decision. Having corporate data off premise in a shared environment, which is how most of the SaaS providers are able to gain economies of scale, is a concern for some customers. Not having data on site, business continuity of the provider and some integration challenges need to be considered when looking at SaaS delivery models. In the end IT and all technologist have to remember it is about the business not technology, unless your business is technology.
SaaS has it's place as do all tools in the technology sector. Is it the end of packaged software? I think it may be to early to tell. In the end I think it is a good strategy for some and has a purpose. The companies that are currently providing software as a service have compelling business cases and drive value but we have to always remember in the big picture it is about the right tool for the job.
To understand the value it is my perspective that we need to look at how we got here. There is much debate on the history of SaaS and how it was derived. From what we have seen in our industry over the years, the Application Service Provider (ASP) industry paved the way for businesses to explore the concept of off premise software, accessed through the Internet or some sort of secure mechanism connecting their enterprise to their provider. Unfortunately the SaaS acronym is not new and was actually one of the original tag lines for a small company in Annapolis, MD. called USinternetworking who was one of the first pure play ASP providers. The concept has actually been around for about a decade now so what has changed?
Having grown up in the ASP / Outsourcing area of our industry the answer to that question is not complex; its the software that has changed. The move to web based technologies, applications migrating to web architectures and new deployment strategies made it easier than ever to support a SaaS model.
Years ago the strategy was to buy one software package that did it all and we saw the rise of Enterprise Resource Planning (ERP) applications. The strategy was solid in the theory that as a CIO I could standardize my processes, platforms and infrastructure to reduce inefficiencies, how bad could that be? What we found is that unless we truly partnered with the business, identified the right project charter or mission statement, the right business objectives and correct stakeholders these projects were sometimes not successful or ran over budget with ROI models that had diminishing returns.
Taking these high level factors into consideration brings the conversation to SaaS. Web based software, coupled with services and the value proposition is clear when it comes to ROI so what are the drawbacks?
Companies and organizations need to evaluate their application portfolios and contrast them against their security strategies and policies. This analysis will drive the SaaS or not to SaaS decision. Having corporate data off premise in a shared environment, which is how most of the SaaS providers are able to gain economies of scale, is a concern for some customers. Not having data on site, business continuity of the provider and some integration challenges need to be considered when looking at SaaS delivery models. In the end IT and all technologist have to remember it is about the business not technology, unless your business is technology.
SaaS has it's place as do all tools in the technology sector. Is it the end of packaged software? I think it may be to early to tell. In the end I think it is a good strategy for some and has a purpose. The companies that are currently providing software as a service have compelling business cases and drive value but we have to always remember in the big picture it is about the right tool for the job.
Subscribe to:
Posts (Atom)
