Reading Questions
- What is the goal of having an enterprise architecture?
- If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
- Explain five possible ways that an enterprise architecture effort could fail?
- Of the six levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
- Does your firm have an EA? How does it affect your day-to-day decisions?
The Strategic IT Transformation at Accenture Case
Think about the following questions as you prepare for our Webex discussion this week:`
- What is Accenture’s core IT philosophy?
- Identify three key IT projects from the 2001 – 2008 period and explain how each strengthened Accenture’s enterprise architecture?
- What measures of success did Accenture use for this effort? Why?
Don’t forget to join our Webex this coming Wednesday at 5:30 with your camera on and your microphone muted.
Rich
I would appreciate it if you could answer reading/case each question in a separate reply/comment. That way I am sure to give you maximum credit for you responses. Remember, we do have a Webex this coming Wednesday, 9/20 @5:30. We will discuss the “Strategic IT Transformation at Accenture” case during the Webex so you don’t need to post anything online in response to the case questions. Just gather your thoughts about the case and be ready to share them during the Webex.
1. What is the goal of having an enterprise architecture?
There are almost as many definitions and descriptions of the purpose and goals of Enterprise Architectures as there are stars in the sky,(Temple should really consider developing a class around these topics;) For example, one stated purpose is;
“Strategy formulation, strategy execution and operation.”
Another definition is:
“..EA helps in setting up how business strategy meets IT strategy, how IT supports those strategies and how systems integration is performed…”
Yet another definition for EA states that:
[The goal of EA] “…is to create a conceptual blueprint that defines the structure and operation of an organization. The intent of an EA is to determine how an organization can most cost effectively achieve its current and future objectives.”
The Open Group defines the goal of an EA as follows:
“ The purpose of an EA is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.”
The Open Group Architecture Framework (TOGAF version 9) page 40
So to understand the goal of EA, one would probably also need to appreciate what problem the various frameworks are trying to address. In other words, (in my opinion), like everything else in life – it depends.
One of the *best* presentations on the differences between the various architecture frameworks (like Zachman, COBIT, ITIL, FEAF and TOGAF) can be found here:
“A Comparison of the Top Four Enterprise Architectures”
https://www.slideshare.net/MohammedOmar4/a-comparison-of-the-top-four-enterprise
Based on this, I think you can essentially break down the goals/orientation of the most popular frameworks into a 50,000 foot perspective:
– Zachman: Categorization
– COBIT: IT Governance/best practices
– ITIL: Service management/operational best practices
– FEAF: Creating a common vocabulary for government
– TOGAF: Creating a common repository of reusable architectural artifacts
I think that they all pretty much accomplish the same thing but each has a particularly unique orientation.
For example both FEAF and TOGAF have their own architectural development methodologies, both have comprehensive reference models,(5 for FEAF, 4 for TOGAF), both attempt to break organizational and architectural structures into more salient ‘domains’,(core mission-area segments, business-services segments and enterprise services in FEAF versus Architectural partitions and domains in TOGAF), etc. ,etc., etc., etc.
In the “Comparison” section of the presentation cited above, the author attempts to rank the top four architectural methodologies on a scale of 1 to 4 (where 1 is inadequate and 4 superior).
The author of the presentation above clearly favors FEAF over TOGAF. I disagree, I believe that TOGAF is definitely the superior architecture framework for several reasons:
REASON 1:
The goal of FEAF is only focused on Federal Enterprise Architectures, TOGAF has a tremendously broader scope.
One of the primary goals of the FEA framework,(among other things), is to establish a ‘common vocabulary’ between governmental organizations. The author provides an excellent example of this on page 24:
“…the problem that the FEA Reference Models are trying to solve on a much larger scale. Suppose the Internal Revenue Service (IRS) decides it needs a demographics system to track taxpayer data. They ask around to see if anybody has one they can modify for their purposes. Nobody does.
Little do they know that, right next door, the Government Printing Office (GPO) has a perfectly good demographics system that is almost exactly what the IRS needs. They just happen to call it a customer-analytics system.
So, the IRS goes out and builds its system from scratch, instead of just modifying the one already built (and paid for) by the GPO. And, in doing so, the IRS will waste considerably more money…”
TOGAF on the other hand *ASSUMES* that a common language already exists (i.e. with TOGAF, Risk management and a Business Value Assessment means the same thing to the company business managers and analysts as it does to the enterprise architect). The goal of TOGAF,(among other things) is to establish a common ‘architecture repository’ where architectural ‘building blocks’ representing REPEATABLE best practices and guidelines are stored – this is something that FEAF doesn’t seem to pay as much attention to.
REASON 2:
Unlike FEAF, the design goal for TOGAF from the beginning was to be completely compatible and complementary to other architectures.
For example, TOGAF Phase F (Migration planning phase) *expects* to accommodate other frameworks like Zachman, the Governance and implementation phases of TOGAF (Phase G & Phase H), assume that there will be interactions with frameworks like COBIT.
To be fair, it could reasonably be argued that most of the architecture frameworks have at least some capabilities to complement frameworks, but none of those were purposely *designed* to do this from the start, (like TOGAF was).
REASON 3:
THE most important reason in my opinion that TOGAF is the most useful of all the frameworks is that BUSINESS REQUIREMENT MANAGEMENT is at the very core of the TOGAF ADM.
Almost every single phase of the TOGAF ADM completely depends on the interaction of each phase with the company’s Business requirements management – i.e., “the quantitative statement of business NEED that must be met by an architecture”. No other framework, COBIT, FEAF, ITIL has this as its fundamental goal.
1. What is the goal of having an Enterprise Architecture (EA)?
As mentioned in a previous post there are many definitions of the goals of Enterprise Architecture. One of the main reasons I believe that is the case is because there is a lot of money to be made in telling businesses how they can better manage their EA.
However, I’m a fan of keeping things as simple as possible, so I will answer this in the simplest way I can. The goal of having an EA is to make you IT infrastructure “current” and “future proof”
The video gave three great characteristics that sums the goals of EA well. Your EA should be Robust, Flexible and Efficient. with each of these characteristics building off of each other
Your EA must be robust enough to handle all of your business needs efficiently while at the same time be flexible enough to allow changes without effecting either the efficiency or the robustness. It is nearly impossible to guess what the future needs of an organization will be (with regulatory or business driven), so the EA must be contracted in a way that it can easily accommodate those future needs.
Vince – I would reinforce the idea that the two key goals of any organization that is seriously implementing EA revolve around using IT to the best advantage possible to support the business. The first is to understand the business strategy and processes of the organization and how, or how not, IT is supporting them today. The second is to look into the future and think about where the company would like to be in the future. Using these two “representations” of the organization, IT investment decisions should then be made to improve the ROI of IT (business value) while positioning the company to be in the best position possible to take advantage of the future (agility).
I am confused about your inclusion of COBIT and ITIL into a list of EA frameworks. Neither is focused on EA although both support its use by organizations. Both are maturity models that help an organization structure how it runs an IT function. Zachman, FEAF and TOGAF are all specifically EA frameworks.
you are correct, COBIT and ITIL are not EA frameworks. BUT both can be integrated into EA frameworks like TOGAF.
I’ll post some examples of references to ITIL and COBIT that I SNIPPED from the official TOGAF documentation where TOGAF DEFERS to COBIT when discussing TOGAF Phase G (IT Governance). I only included a couple of examples because, frankly I was getting writers cramp;););)
I like the last two examples from TOGAF Version 9 (Architecture Document) which references mapping TOGAF 8.1 to COBIT 4.0 and the statement confirming that TOGAF aligns with COBIT.
EXAMPLES
TOGAF Version 9 Architecture Document page 18
2.10 Using TOGAF with Other Frameworks:
“Because TOGAF is a generic framework and intended to be used in a wide variety of environments, it provides a flexible and extensible content framework that underpins a set of generic architecture deliverables.
As a result, TOGAF may be used either in its own right with the generic deliverables it describes; or else these deliverables may be replaced or extended by a more specific set defined in any other framework that the architect considers relevant.
The architecture tailoring may include adopting elements from other architecture frameworks, or integrating TOGAF methods with other standard frameworks such as ITIL, CMMI, COBIT, PRINCE2, PMBOK and MSP.”
TOGAF Version 9 Architecture Document page 57
5.4 Architecture Governance:
“…the major information areas managed by a governance repository should should contain the following information:
– Reference Data: (collateral from the organizations own repositories/Enterprise
Continuum, including external data; e.g. COBIT, ITIL): Used for guidance and instruction during project implementation. This includes the details of information outlined above. The reference data includes a description of the governance procedures themselves…..”
TOGAF Version 9 Architecture Document page 415
34.4.1 Governance Extensions:
“Purpose:
The governance extension is intended to allow structured data to be held against objectives and business service, supporting operational governance of the landscape.
…in addition to the extensions described here, organization wishing to focus on architecture governance should also consult:
– The COBIT framework for IT governance provided by the Information Systems Audit and Control Association (ISACA)…..”
TOGAF Version 9 Architecture Document page 675
47.4.1 General:
Architectural board meetings should be conducted within clearly identified agendas with explicit objectives, content coverage, and defined actions. In general board meetings will be aligned with best practice, such as given in the COBIT framework…”
TOGAF Version 9 Architecture Document page 707
50.1.4 IT Governance
“….As with corporate governance, IT governance is a broad topic beyond the scope of an enterprise architecture framework such as TOGAF. A good source of detailed information on IT governance is the COBIT framework…”
“…COBIT controls may provide useful aids to running a compliance strategy. A comprehensive mapping between TOGAF and COBIT that guides the practitioner in implementing architecture governance aligned to IT governance:
Mapping of TOGAF 8.1 to COBIT 4.0 by the IT Governance Institute (ITGI)…..”
TOGAF Version 9 Architecture Document page 712
50.2.2 Architecture Governance
“…..the following benefits have been found to be derived through the continuing governance of architectures:
…………ALIGNS WITH INDUSTRY FRAMEWORKS SUCH AS COBIT (Planning and Organizing, acquiring and implementing, delivering and supporting and monitoring IT performance)…………”
Anthony – I worry a bit about your phrase “your infrastructure.” Done well, EA should involve a lot more than just the network and computing power that an organization utilizes. I have seen IT organizations tying to upgrade their infrastructure to make it more “future proof.” They tend to have trouble getting funding because the business leadership does not see the connection between these investments and the success of the company. Leadership in a digital company may have enough understanding of the technology to see the connection but its a stretch for the leadership of many traditional non-digital companies.
I can’t speak for other companies, but I can speak for the one I work for in regards to EA. I currently work in the financial industry and you would think that convincing the business on the merits of keeping your tech current would be difficult due to the fact that you are dealing with financiers and bankers, not technologist.
However the opposite is much closer to the truth. The financial industry is evolving into the digital environment and the amor firms (including my own) realize that your IT infrastructure as to constantly evolve to keep up with it. The bottom line is to increase revenue, and you can’t do that in today’s market if you are behind the power curve in regards to IT. Therefore, the leadership of the business always eager to listen to new ideas of how we can improve our standing in the digital arena.
Following up to my follow-up, I can answer Question (5) Does your firm have EA? How does it effect your day-to-day decisions?
Yes we do have a firm wide EA, and it is broken down into separate units that support each Line of Business (LOB). Their main role is pretty much in line with the descriptions given in each of the readings. They pretty much serve as the “liaison” between the the technologists and the business. They can speak both “tech” and business”, so they are able to explain to each side the merits and shortfalls of their positions..
I routinely interact with EA within my LOB when it comes to the adoption of third party vendor systems, which usually involve new POS devices or merchant systems. My team provides Risk Oversight for any new systems being adopted into the firm. Its our responsibility to ensure that the “new deals” are within our firms risk policies and guidelines.
Anthony,
Do you run into issues or situations where a business unit wants to use a new vendor but a system already exists in house that performs the same function? I’m trying to gauge how prevalent it is to have separate systems and then have to figure out ways to integrate the data. Example – we have a vendor for multi-factor authentication for our online member facing system, another business unit is responsible for the new member application and would prefer to use different vendor for additional authentication (whether it be knowledge based authentication, risk based, etc.) so the possibility exists to have 2 vendors that have similar capabilities performing the same function with no integration.
Thanks, Michael
Michael – wow, excellent example. It highlights current needs (?) versus future state. A quick point for everyone, the needs/desires of different LoB’s do not necessarily match the needs of the corporation, either in aggregate or average. We will talk next week about the politics of this.
The answer is a little more complicated than yes and no, but I can give an example. Within asset servicing many of our application/systems perform basically the same function (moving money between client accounts), but they perform them on different product lines. A lot of the times these products aren’t even different security types, only securities who’s metadata is provided from a specific trading platform. Any one of these applications could easily handle all of the functions from every product type, but vendor agreements prevent us from doing that. Therefore, we have overlapping capabilities from different application.
We are in the process of alleviating that though. In the near future we will be transitioning to a single vendor run platform that will take over a majority of the duties of these disparate platforms.
Anthony -Great example. I think of finance as a digital industry, after all they are moving data around not piles of money or stock certificates. The more the business is based on data, the more a strong EA is needed. Digitization is now spreading to other industries which have not had a strong need for EA in the past. While we had network, platform and application standards in the chemical industry our EA development was week. Since SAP was originally designed for chemicals, we often just relied on what they suggested. I wouldn’t want to be taking that position today.
Others? Please give us an idea of what industry you are in and how strong you think your EA efforts are.
I am also in the financial services industry but we do not have a formal enterprise architecture (which is odd because our entire business model is branchless, self-service, technology oriented). We have many silos of specific products/services and those groups know their specific products/services inside out but I can see where having a formal enterprise architecture in place would benefit the entire organization. Because so much has been developed in house to integrate these products or services, it is very difficult to deploy something new due to the risk of breaking an undocumented dependency.
Michael – integration is the key, its extremely costly and difficult for a business. Assuming multiple LoB’s, it makes it very difficult for a business to give its customers complete line-of-sight across all of their (the customer’s) business.
I feel your pain and we DO have a robust EA presence. The project I completed in my last role dealt with shortening the settlement cycle on US based securities. We identified over 300 applications/systems that were inscope for the transition and roughly 1/3 of them required some sort of functional change. The problem I ran into was that over numerous mergers our settlement system became a hodge lodge of in-house, vendor provided and acquired systems. It was such a mess that we were never really sure what effect a change in one application would have on other ones within the system. This caused our testing to extend longer than planned, but in the end it all worked out.
We are now in the process of retiring a bunch of those systems and replacing them with a single suite of applications from a single vendor.
Hi, Vince, Anthony and Prof. Flanagan,
Anthony and Vince, I truly agree with your comment relating to a large number of definitions for EA “I think that they all pretty much accomplish the same thing but each has a particularly unique orientation.” During our readings, there were several depictions of how the writer interpreted (in my opinion) the foundation or core purpose of EA.
However, Professor, your comment/definition “I would reinforce the idea that the two key goals of an organization that is seriously implementing EA revolve around using IT to the best advantage possible to support the business” were very clear. I believe this was indeed the thought process within my workplace when they converted our system, which by the way is very useful now… Thank the C-levels for their understanding to the need for alignment.
2. If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
Again, as in question 1, I would think that ‘it depends’ on what framework is being used.
TOGAF based enterprise architectures are designed to accommodate either incremental or wholesales changes (like adding a new line of business).
TOGAF ADM defines a set of eight development ‘states’ or phases,(phase A to phase phase H). These phases revolve around the company business requirements (in this case the new line of business). Each phase addresses some aspect of the overall business/architecture need.
For example; phase A is the architectural vision,(what you need to achieve), phase B is the business architecture, phase C is the IS architecture (applications and DB architectures), phase D is the technology architecture, etc. etc.
All of the phases are linked together by an Architecture Definition Document (ADD). The ADD is initially developed in phase A then passed on as input to phase B. The output of phase B is an ADD that represents the aggregate output of phases A & B. The aggregate ADD then becomes input to the next phase. This process continues through all of the phases in the cycle until you are left with one holistic view of the enterprise representing all of the phases (A + B + C + D + E + F + G + H).
This process can be used in a holistic fashion (starting at phase A and proceeding all the way through to phase H) or as combinations of ‘iterations’ based on need.
All the inputs and outputs from each of the phases in this process are also captured as ‘architecture artifacts’ and kept in an ‘architecture repository.’ The repository contains guidelines, best practices, industry and organizational reference models as well as the SIB (Standard Information Base) – a collection of predefined standards from the creators of TOGAF.
The most basic element in the architecture repository are ‘Building Blocks’. These are organization specific processes, procedures, etc. that are intended to be reused.
So in the case where the company needed to add a new line of business, it would simply ‘glue together’ the building blocks that were common to the company,(previously placed in the repository from other ADM events). This would form the basis of a ‘skeleton current state’ for the new line of business.
At this point, the EA development cycle for the new line of business would begin – each phase would start with the ‘current state’, define a ‘target state’ for that phase and draw a gap analysis between the two. In the end, the aggregate gap analysis from all of the phases ultimately becomes the roadmap for how to get to the target state of the new line of business.
The point is that, because of the TOGAF goal of reusability and the fact that TOGAF abstracts much of the business and technical dependencies away, it allows you to make what would seem to be radical, disruptive changes to the entire company’s enterprise architecture relatively easily.
3. Explain five possible ways that an enterprise architecture effort could fail?
EA efforts can fail in any number of ways. Some examples include:
1. ‘Tone from the Top’. Enterprise architecture departments/organizations are often thought of as ‘ivory tower academics’ whose ethereal pedantic ideas and suggestions add little value outside of a compliance checkbox and certainly don’t help to drive revenue for the company. Without strong and highly visible support from senior management, anything that is produced by the EA team will simply be treated as nothing more than suggestions and guidelines.
2. Misaligned Architectural Vision: Without clearly understanding or articulating what the ‘target state’ should be, the entire effort would be based on (potentially) faulty assumptions
3. Again using TOGAF as an example, failure to assess the current state – i.e., establish the proper understanding of what the baseline is – in *any* phase of the ADM process.
4. Not keeping the stakeholders abreast of progress, not conveying what the tangible benefits of achieving the target state will be for the stakeholders, not including multiple stakeholder views and viewpoints or failing to reconcile dissenting viewpoints in an equitable manner almost guarantees failure.
5. Failing to adhere to appropriate architectural governance – e.g., failing to ensure that changes conform to established standards, that the stated functionality doesn’t deliver on the intended business value or align with industry accepted enterprise architecture best practices. Failing to maintain and keep the architecture repository relevant, (letting the repository become obsolete).
6. Failing to orient each TOGAF phase around the business requirements.
7. Creating unique ‘snowflake’ implementations for every solution – as opposed to demanding standardization and reusability above all else.
What is the goal of having an enterprise architecture?
Enterprise architecture, as it is, helps IT and business design policy and practice that guide the organization implement a strategy effectively. In short, enterprise architecture helps arrange IT and business concern to meet the organization current and future goals.
Enterprise architecture gives a picture of the present and future look of system or business. How business and IT strategies implemented to achieve the organization goals. Though EA is heavily connected to change management, yet new product will impact enterprise architecture.
Depending on the size of the new product, EA will have a great change which will affect other departments, communication, finances, project management structure, redesign of the present framework or alignment (business, IT, application, and infrastructure) to achieve organizational goal. A new product could change the present and future state of an enterprise architecture.
In short, a new product will affect enterprise architecture structure: examination, plan, implementation, and structure.
Pascal, I agree completely with how EA is connected to many different aspects of an organization. The future goals and/or plans that an organization has will greatly affect the Enterprise Architecture plan for the future. A new service being developed, mergers/acquisitions of other companies, and even outsourcing can change the Enterprise Architecture of an organization.
Explain five possible ways that an enterprise architecture effort could fail?
Enterprise architecture looks at the present, but developing an EA that is more adaptable to future change is of great essence. The success of EA is predicated upon many variables. Five of those variables are:
Architects/staff: selecting the right architect and team is key to the success of EA. If the wrong architect or team is selected, there could be limited skills, communication lapses, strategies, enthusiasm, etc.
Stakeholders & Support: In other for stakeholders to support a project they must first understand all of the variables in the project and expected outcome. Understandability includes stakeholders participating in the EA campaign. To increase stakeholders understandability, they must be educated and there should be communication effectiveness. Less, stakeholders will have less interest and support will be impacted negatively.
EA policy (governance): though every project will have its own rules or standard, the must a policy set to guide every enterprise architecture. If EA governance is structure, there is good chance of failure.
Communication: timely communication and the content of communication (message) is paramount to the success of the an EA. Every stakeholder will not understand the reason for the change. How the message is view and when it is viewed is key.
Stipulation: EA is more “IT” focus, but there is a need for business professional import. For EA success, business and IT professionals must collaborate to develop EA framework. Where necessary, all unit must be included. IT professionals cannot see the business effect while business will not see the IT effect. Thus, without collaboration failure is sure.
Pascal – I like your stipulation. Many business people in non-digital companies fail to see the value in participating in EA projects. They often have no time for it because, “there is a business to run.” Yet we all know that more and more of every business is becoming digital. Those non-digital companies that recognize this and put in the effort on EA will be much better positioned than those who do not.
Pascal, in reference to your comment on “Architects/staff”, SMEs and experienced/knowledgeable resources are essential in order for EA projects to succeed. From an overall project management and IT management perspective, your SMEs are going to be your most valuable players and it is essential to keep them satisfied from a HR perspective to stay on track to deliver when faced with tight deadlines and complex Enterprise Architecture. If your MVPs leave mid-project, that can leave you with a huge disadvantage should the project architecture need to change or should any issues arise which require a change control.
1. Of the four levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
IBM defines the four FEAF levels as follows:
Level I:
The highest level of FEAF. It introduces eight componentsfor developing and maintaining FEAF. These include:
1. Architecture drivers
2. Strategic direction
3. Current architecture
4. Target architecture
5. Transitional processes
6. Architectural segments
7. Architectural models
8. Standards
Level II:
Provides a greater level of detail of the business and designs aspects of FEAF and how they are related
Level III:
Level III further elaborates on the design details of level II. Level III expands the design pieces of the framework to show the three design architectures which include:
– Data architecture
– Applications architecture
– Technology architecture
Level IV:
Identifies the kinds of models that describe the business architecture and the three design architectures; data architecture, application architecture and technology architecture. It also defines enterprise architecture planning and how the business architecture is supported by the three design architectures in a more explicit way.
In terms of “Which is most addressed?” I’d assume that the question is asking which level is used most often? If so, I’d think that Level III is used most often because it provides the most explicit detail.
For the question; “Of the four levels of the Federal EA model which do you think is most important?” I would think that, again, it depends.
If the purpose was to familiarize myself with the business, interact with senior executives or to try and gain an understanding of how the architectural information was organized or what architectures were appropriate for the specific enterprise, I would rely on FEAF Level IV, because level IV identifies the *kinds* of models that describe the business, data, application and technology architectures.
If on the other hand, if the purpose was to interact with the organization from a technical perspective, I would rely on FEAF level III because it provides the greatest amount of detail of all the levels.
1. What is the goal of having an enterprise architecture?
The goal of having enterprise architecture is to add foundation / blueprint to the business’ IT organization. Enterprise architecture ensures that the ‘plumbing’ of the IT environment can be flexible enough to respond to current and future needs.
Tameka – EA is really about more than the plumbing. It needs a strong understanding of how the firm makes money and what its major processes are. Anthony stated that the EA in his firm was by line of business (LoB). I can give an example using 2 of our 10 LoB’s. One was a commodity chemicals business that moved massive amounts of chemical at very low gross profit, single digits. Another was a specialty product that made one or two batches a year, but sold at high double digit gross profit. If your EA didn’t understand the nature of these two very different LoB’s, you could wreak one by increasing IT costs to more than it could afford, or starve the other by not investing in high sophisticated and expensive IT tools to help it sell.
Thinking about EA from a different perspective, for some sort of scenario which is non-IT related. I’m picturing roadway construction. You can go and build a road anywhere you want, however it can’t be called a successful road or even a safe road unless you understand how it will be used, the demand for it’s use, the different intersections which will complicate driving on the road. The Enterprise Architecture of this road must also consider these factors and implement certain controls, guidelines, and include the intersections within the plans.
2. If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
Adding a new line of business may affect enterprise architecture because the organization has to able to understand the implications of adding new line of business. Will the new line of business require a change to system, policy, or otherwise. As an example, if the current system is not configured to account for the new line of business, enterprise architecture would need to provide enterprise architecture services (APO03.05). This could include providing guidance on technology that should be selected that lines up with the new business need.
Everyone – do you see the connection back to the Your Neighborhood Grocer case. Clearly there was no EA thinking involved in their acquisitions.
From our Accenture case tonight, it looks like Accenture has been making some very strategic acquisitions to enhance their service offerings.
https://newsroom.accenture.com/news/accenture-acquires-search-technologies-to-expand-its-content-analytics-and-enterprise-search-capabilities.htm
3. Explain five possible ways that an enterprise architecture effort could fail?
An enterprise architecture effort could fail because:
A. People are unaware that they exist.
B. They have no weight within the organization. Their suggestions / solutions are not heard.
C. They are no longer credible. Previous involvement of EA had unintended consequences including significant delays or unanticipated system issue.
D. The cost-benefit analysis is unfavorable. The cost of the EA organization outweighs benefits being provided.
E. EA organization does not interact with the business. They are directly removed from their customer and are no longer in alignment with business strategy.
Regarding D, I would think that an EA organization falling short on a cost-benefit analysis indicates a failure of the EA team in explaining the usefulness to management, both in quantitative and qualitative ways. Certain innovations may indeed be cost-prohibitive, but is it possible for them to be entirely cost-prohibitive? I would think a firm interested in planning ahead would want EA in at least some form. This article provides a useful explanation for the value EA provides to a firm and asserts that a cost-benefit analysis in such a strategically oriented organization is very difficult.
http://futureofcio.blogspot.com/2013/10/how-to-perform-cost-benefit-analysis.html
Michelangelo – nice article, thanks for posting it. I would say that it is possible for EA to be a value destroyer, rather than enhancer but its hopefully rare these days. My negative case would start with an ambitious IT manager who is enthusiastic about EA. Without good IT governance, he or she might start a big EA project in the absence of any buy-in from senior management. After spending a lot of money, the EA output might be completely ignored and then the company sees all costs and no benefits.
Yes, there is enterprise architecture at my job. Matter of fact, there is an enterprise architecture division.
Example, the replacement of administration system with an integrated solution that would increase efficiency, allow the institution to adapt quickly to changing tax policies, and reduce complexity and cost.
This was done by the enterprise architectural division and key stakeholders. To achieve this goal, a blueprint was developed that define the structure and operation of the institution. The idea behind the setup was to determine how the institution will achieve it present and future goal with the change.
With the modification, there are more to learn and implement. Documenting activities, reporting errors, implementing functionalities, and adapting to the new environment. Most of the day-to-day decisions are based on the changes, in particular with the implementation and improvement. There is always changes during the day. At one point, I was logging on server 1.2 to perform some duties and some functionalities, but EA requested I log on to server 1.4. As each server was serving a special route, server 1.2 needed lesser load. That made my day a little slow, but there was no other choice. It is getting better; the change is becoming effective and achieving its goal.
5. Does your firm have an EA? How does it affect your day-to-day decisions?
Yes our EA is based on TOGAF,(surprise;). Just my opinion here but I think that the BEST enterprise architecture should be almost completely invisible to the end user and should only manifest itself in the, (standard AND transparent) processes and procedures that everyone adheres to and benefits from.
One of (many) impacts of our EA on my day-to-day decisions is that our commitments to our customers are *extremely* reliable. When one of our business units produces their development roadmap and timelines and the deliverables on those roadmaps are designated as “Engineering Commit”, you can be *extremely* confident that those deliverables will be available in the specified time that they say.
The following are some of the benefits that our EA team points to:
• A common method and training has simplified processes and saved time.
• Having a Target State and well-communicated principles (on our architecture) has helped with proper alignment across the business.
• Common processes for measuring means that our design compliance is more accurate and that we are able to make changes more easily and consistently.
• Re-use of software components saves time and money.
• SSOT (Single Source of Truth), COGS (Cost of Goods Sold), Bookings, Expense management costs are minimized.
• Web Services Management infrastructure is more solid and aligned with other services.
• Broader awareness of changes needed leads to broader adoption.
• We now have a single EA Council that has responsibility for resolving issues, discussing strategies and ensuring that EA is including in business architecture going forward.
The FEA model makes much sense; there are lots reasons (cost, uniformity, maintenance, monitoring, collaboration, and staffing) to justify the model.
The hierarchy is necessary, but there is no way one level can be separated from the pyramid. Regarding the importance of each of the level, business appears to be the most important. At the business level, there is a complete package (data, application, and technology). Technology which supports the other levels is worth nothing without application, an application that process data accordingly means nothing without data, if data are useless to the business then there is no need to have them. Once there is business, there is a lot to do – protecting data, application, and technology. All of the other levels support the business goal which makes business the most discussed. There is a lot about the business level. There are discussions about business functionalities and processes, and all the other level discuss how they will contribute to the goal of the business.
At the business level, you get some questions and answers:
a. What is done – the action;
b. Who did it – staff;
c. How was it done – data, application, and technology;
d. When was it done – time; and
e. Why was it done – reason?
These questions and answers trickle down to each level.
source: ” https://www.whitehouse.gov/omb/fedreg_a130notice“
What is the goal of having an enterprise architecture?
From the week’s materials, it would seem enterprise architecture is best understood as a way to simplify an inherently complex IT landscape in a given business. This simplification allows the business to make improvements and innovate without causing interruptions in applications or the entire landscape. It is divided into three main activities: first, to evaluate the current IT landscape situation at the business, second, to develop and analyze designs for the enterprise architecture to provide the aforementioned ability to improve and innovate without issue, and third, to create a plan for future operation and growth of the architecture so that stakeholders understand what to expect going forward.
If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
Explain five possible ways that an enterprise architecture effort could fail?
Of the four levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
Does your firm have an EA? How does it affect your day-to-day decisions?
Michelangelo – Best to think of this as understanding the complex interconnections of the business and IT. Change one and you will change the other (in a planned way or in an unplanned, and often negative, way). The steps you outlined are good but you need to change the order.
1. Understand all the connections between business and IT (process, data and business rules).
2. Understand where the business may want to go in the future.
3. Make decisions about improving # 1 with # 3 in mind. That way you are leveraging you capital investments to both improve current business performance and move you to the future state.
Thank you for the clarification. So in other words, the firm needs to understand its IT landscape as it currently exists, with the various processes, data and business rules/policies. Knowing this, they should determine where they want to go. This could involve some innovation strategy, perhaps looking at upcoming mergers/acquisitions. With this being known and documented, a strategy for implementing EA would effectively address current and potential future needs.
What seems a bit difficult to me with the ‘future’ aspect is that the firm may not have a sense of what a new business unit is going to bring to the table in terms of its IT landscape, processes, and use of new or old applications. I imagine some consultation occurs after the deal is agreed upon and integration begins, but until then, wouldn’t the new unit be withholding this info to avoid sharing proprietary info or intellectual property? If this happens, then future planning would not be able to accurately gauge the upcoming needs of the firm.
Michelangelo,
I agree with the “future state” aspect. Even taking mergers and acquisitions out of the equation, we have trouble seeing the “future state” because there isn’t a clear picture of what the organization wants that to be. We do 3-5 year strategic plans and once they are approved and finalized, as soon as someone goes to a conference and sees a new technology or an article saying this is the next best thing, a project gets prioritized and the vision has changed again. From there, the challenge would be getting a dedicated team for enterprise architecture who would have the authority or leverage to keep everyone back on track or adopt items that fit into the organization and tie back to the strategic plan.
Made a mistake by having all the questions in the first post. Woops!
If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
The business addition will mean requires resource and possibly new processes or applications. Perhaps new software needs to be made entirely from scratch, or new developers’ skillsets are required. Using TOGAF Framework, we would want to incorporate this new part of the firm into the needs of the business overall, to be handled via the Architecture Development Method. Those new needs must run through the ADM cycle, with the eternal focus being on the requirements as set forth by management, both within the larger firm and in the new line of business. After this, a final architecture would then be fed into the Content Framework, thus allowing an accurate understanding of how the firm’s enterprise architecture now looks and functions. Moreover, the new business processes need to be included in a revised future plan for the enterprise architecture and the firm overall. Without incorporating new business into the planning, the plan will not accurately reflect the future trajectory of the firm as it continues to add new business lines.
Explain five possible ways that an enterprise architecture effort could fail?
At a fundamental level, EA could fail if architects setting it up inaccurately identify the needs of the stakeholders and thus create a system not truly designed to meet those needs. This might mean a misunderstanding of what applications are mission critical and which are just nice to have, or it might be some miscommunication between architects and multiple business units all with unique needs and wants.
In that vein, EA could fail if the firm’s stakeholders don’t know they want or need – something entirely possible if they have never performed an audit. This might be the case in a new or small firm, or perhaps if management has been slow to innovate. People can be a little foolish, but one would hope this isn’t the case!
As described in the McKinsey article, one big failure mode could be an EA team lacking in the necessary interpersonal skills to communicate their value and contribution to the management team. If the EA team cannot explain what they do or how they do it to management, then their value will be diminished.
I think another possible failure could arise from the architects and management not including all the business units of the firm, perhaps because of a high frequency of acquisitions that year. This means that any resulting architecture won’t accurately describe or include all pieces of the firm.
One final failure mode, also alluded to in the article, is a c-suite not quantifying the benefit to the firm of the EA team. By not having hard numbers to show how they contribute to the firm (e.g. lower labor costs from replacing an older application), architects risk being sidelined or de-funded in a fiscally tight quarter, to the detriment of the firm overall. Combined with management not understanding what EA even does, this could be disastrous and unexpected.
Of the four levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
Since the levels build off each other, we can look at the highest two (Performance and Business) first. Of the two, I’d say that Performance is most important. In a corporation, Business would reasonably be considered most important, as it ensures that the firm understand its units and relevant customer base and partners. The federal government also has these, but they are citizens and perhaps other departments within the fed, or perhaps state and local. However, performance means that the EA framework is going to provide uniquely tailored performance indicators. An example would be air quality numbers to meet for the EPA – something that the Dept of Energy may not concern itself with. Each department must tailor its PI’s to its unique needs, as determined by both the overall government and the citizens and Congress, so this seems most important to me. I believe that the most addressed level is the Performance one, though it might be Data Reference. I say DR because many departments are attempting to standardize the IT landscape and update legacy systems, with the VA being an example of one such agency striving to digitalize medical records for easier access and integration into multiple record systems.
https://www.ibm.com/support/knowledgecenter/en/SS6RBX_11.4.2/com.ibm.sa.irma.doc/topics/c_purp_Fed_Enter_Arch_Ref_Mdls.html
https://ehrintelligence.com/news/va-transfers-paper-records-to-ehrs-in-modernization-effort
What is the goal of having an enterprise architecture
The goal of enterprise architecture is to create a unified IT environment standardized hardware and software systems across the firm or all of the firm’s business units. The enterprise architecture development is to process of planning and designing the information Technology capabilities of an enterprise. If you are familiar with OSI networking model this is an abstract model used to illustrate the architecture of a networking stack. A networking stack within a computers very complex because it has so many protocols, interfaces, services and hardware specification and Implementing a new business process management methodology. Automating and optimizing primary business processes. Supporting new products. Adapting IT systems to meet new market requirements Estimating required investments in technology transformation. Manipulative potential financial and efficiency returns from the planned IT strategy
Syed – A couple of key points that I want to make sure you get:
1. EA is about much more than IT standards. This is often a point of failure when IT does EA in isolation. You need to understand the business needs an drill down to infrastructure, otherwise you can miss key, legitimate, needs of some LoB’s. Check out my earlier post with a real example of two very different LoB’s in the same company.
2. Centralization is not always the best answer. It often is, but not always. A private equity firm may own many companies but they are unlikely to integrate anything below the highest level of external-reporting accounting because their goal is to sell each of the companies separately at some future time.
2. If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
As a new business strategy is developed by the firm, new or modified enterprise architecture may be needed (this could be determined by a gap analysis). This enterprise architecture needs to take into account and the existing embedded base of IT assets, the existing enterprise architecture, the existing enterprise architecture standards, the firm’s principles and practices, the desired business strategy, and the available frameworks/tools to develop a new enterprise architecture or modify the existing one. The output of this synthesis will be a set of derived IT strategies, a new/modified enterprise architecture a roadmap describing the IT projects needed to effectuate implement the new architecture and achieve the target state, and a development/deployment plan.
Mohammed, you broke it down very well. Adding a new line of business can come about from two main ways which might prompt a different EA approach for each scenario. One way an organization can add a new line of business is by splitting it off from an already existing LoB. If one LoB becomes too large and complex and there is a clear way to improve efficiency and effectiveness by splitting it into two different unique LoBs, the EA impact might end up being less expensive and require fewer resources as the organization may be able to continue using the current architecture or only need minor changes.
If the organization adds the new LoB through added responsibilities and/or added services, this can be much more expensive and time consuming as many times it requires a completely new architecture to be planned, developed, and tested.
3. Explain five possible ways that an enterprise architecture effort could fail?
1. Underestimating The Impact of Change
Resisting a change can easily kill any project. The leaders of the project – project managers, technicians, and all other people working on these projects must represent a positive force that will constantly promote the vision and the future state after the change. Company’s employees will cooperate if the attitude of leaders of the initiative is positive. Addressing resistance problem’s and helping them accept the change can bring many benefits to EA implementation and ensure better results. One of the key benefits a single enterprise architecture software tool will bring is quality impact analysis.
2. Companies want everything, but don’t want to invest money and time. Many projects are completed with this strategy, but almost every time they are late, over budget and missing many important features which affect the quality of business processes. Doing thing cheap can often cost the company more money in the long run. If the project is lacking resources it is likely that features will be missing, framework won’t be tested properly and people will get burned in the process.
3. Poor Communication
Enterprise Architecture projects usually extend to a large number of people. This means that constant communication is required at all levels throughout the company. Strong communication can help a lot with the project. With a combination of meetings, emails, blogs, group meetings, bulletin boards and other mechanisms successful enterprise architecture implementation is guaranteed. How can an enterprise architecture software tool help? Use business friendly diagrams and models as a key communication tool. Pictures say a thousand words.
4. Lack of Sponsorship
Enterprise architects need the following tools to do a good job:
– leverage
– access
– goodies
Leverage means the authority to stop unsuitable technology implementations, partaking in governance, access to relevant reports and capability to influence the technology budget.
Access includes interaction with the stakeholders, usually at the C-level.
Goodies involve the access to new technologies for testing, ability to “lend” experts to struggling projects and access to exclusive information.
5. Hiring The Wrong Person
If someone holds the EA position, it doesn’t automatically means that the person is a strong EA. Often the most technically competent people are hired, even when they are lacking other important skills. These skills involve the ability to translate technical documents into simple business strategy, knowledge about the business, the ability to communicate, listen and present enthusiasm for new technologies.
Conclusion
Besides the reasons on our list, there are many additional reasons why EA implementations fail. The potential success or failure is largely influenced by the company’s culture, politics, and organization. Looking at successful EA implementations in the other companies is not always a reliable indicator whether your company initiative will succeed.
Knowing why initiatives fail is a good starting point to improving success rates of EA implementation. Here’s a short success formula for enterprise architecture initiatives:
1. Build solid business case
2. Find a reliable top level sponsor
3. Create a Road Map
4. Present the Road Map
5. Encourage others to Follow the Road Map
6. Deliver results constantly
7. Add value
8. Lead
great points – I especially like your observations about communications,(and open collaboration). Your dead on – doesn’t matter how detailed or specific a plan/architecture is, if its purpose and value isn’t clearly articulated to everyone – consistently – as opposed to just spewing a bunch of words at the beginning, middle and end of the implementation of anything, then its bound to fail.
Also agree on the Roadmap observation. In fact, when you boil everything down, isn’t that the essence of any architecture ? (Target state – current state = gap), i.e., ‘here is where we are now’. ‘here is where we need to get to’. here’s whats missing in order to get there.
Everyone – Vince has put his finger on a pattern that will appear over and over again in governance. The very logical structure that is used often in COBIT processes is figure out where you are, then where you want to be and then what the gaps are Only after that can you take action relatively confidently that you are helping and not hurting.
This is a nice list, and I particularly like your reference to the three tools EA staff need to succeed. I think leverage is particularly relevant because of the underestimated value the EA folks have in some organizations, as has been mentioned in the week’s readings. The c-suite or other stakeholders may not recognize the architects’ value, and therefore the architects must struggle for any leverage or access to stakeholders. A robust and well-designed architecture may not work if the staff cannot govern, or for example if new business units come onboard without an analysis of their applications, thus giving architects less ability to avoid poor implementations.
1. What is the goal of having an enterprise architecture?
• The goal of enterprise architecture is to strategically align the agency for growth and expansion if need be. In order to have this readiness, the IT landscape/architect has to be technically robust, flexible and efficient. With the IT landscape build this way, an agency keeps itself innovative and open to improvements.
Duy – don’t forget the here and now. Yes you want future agility but you also want current IT to be a effective and efficient as possible.
Professor, I’m with you on ensuring that the Current and Future architecture is very important, however, in your experience do you think many companies focus too much on the current and neglect planning for the future? Or focus too much on the future, and neglect the current EA?
2. If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
• Adding a new business would add new business strategies, perhaps new applications that need to be implemented and new IT needs. Perhaps the new business has new industry guidelines or standards that the agency now needs to address. There are lots of questions that need to be answered and lots to be considered. Does the new business need a new application or current applications be modified to fit its needs? What are the new IT needs vs what we currently have? The agency needs to know if the current IT infrastructure, IT strategies, IT processes, ect.. can support this new business
3. Explain five possible ways that an enterprise architecture effort could fail?
• Implementation of enterprise architecture requires buy-in from all sides, from business leaders to IT heads. Lack of sponsorship or input from either group would fail EA efforts. This buy-in also extends to non-managerial staff that must carry out these initiatives.
• Implementation of incorrect solutions. Not understanding fully the business and how it relates to the technology being deployed can fail EA from the very beginning.
• Failure of management to communicate correctly the strategies and initiatives for implementation of EA. Executive staff or IT committees can have the best plans for implementation of EA strategies, but if these plans are not shared correctly through-out the agency it creates a big risk for failure.
• Organization not correctly analyzing the baseline first. Not know where the organization is and where to start would be another failure of EA. How would an agency know what it needs to do if they have no idea of where they currently are? EA planning needs an accurate assessment of current condition, type of systems, number of systems, what these systems requirements are and which is replaceable. These are some of the questions that need to be answered before EA strategies can be established.
• Organization has not correctly set expectations for EA and has not set Key Performance Indicators (KPIs) to measure success. KPIs or any type of measurements for change is needed in order to evaluate if these initiatives are correct and is working as intended. KPIs are also crucial for spend analysis and evaluations of ROIs.
5. Does your firm have an EA? How does it affect your day-to-day decisions?
• Based on pass projects I would say that my company does not have a clearly defined Enterprise Architect framework or strategy. There are no IT committees and IT projects do not have an approval process. Projects are not reviewed extensively. Currently we are running Oracle PeopleSoft for our enterprise Financials, HR and CRM needs. With other applications running for other purposes. New applications are not implemented frequently but when there is this process is usually ran with some input from the IT team. There are no clear cut processes or procedures in line for new projects or new business requirements. But there are some considerations for existing applications that can be develop to meet new business needs. This is an informal process for the CIO and is not documented in anyway. In addition there is some consideration to have new application somewhat compatible or ability to integrate with Oracle products.
Duy – same question as for Michael, how big is your firm (people or revenue $’s)?
PHA is Federally funded, roughly $250 millions and about 1500 employees.
The Strategic IT Transformation at Accenture Case
Think about the following questions as you prepare for our Webex discussion this week:`
1. What is Accenture’s core IT philosophy?
• Accenture core philosophy in my opinion is using advance technologies and best practices in IT implementations. Accenture had previously been known for assorted consulting services in addition to traditional financial audit services. Once Accenture had broken away from Arthur Anderson, the branch had become an installation provider for business software SAP.
2. Identify three key IT projects from the 2001 – 2008 period and explain how each strengthened Accenture’s enterprise architecture?
• New IT Governance: One of the most important projects that Accenture implemented to strengthen its architecture has to be new IT Governance. This project laid the ground work for current and future projects. The new governance established IT steering committee to make major IT decisions. Because of this alone changed the IT philosophy of the firm. The formation of these committees and formal process brought a new vision to Accenture’s long and short term IT commitments. ROI analysis as well as defined audit plans of all projects allowed Accenture to evaluate and re-evaluate the value of all projects on a consistence basis.
• Selection of a Platform: Another projected that greatly shaped Accenture IT culture is selecting the platform or IT strategy. Choosing to go with the one-platform approach rather than the best-of –breed approach centralized and standardized Accenture globally. Implementation of SAP and Microsoft greatly reduced Accenture IT support overhead and expenditures with licensing and maintenance fees. Running one-platform also reduced the number of specialists that were needed to support the multiple applications that used to exist. Training and managing one application also increased the efficiency of Accenture’s staff.
• Choosing an enterprise Application: With a single ERP, Accenture became highly integrated. Consolidating all their financials and HR applications gave Accenture a global monitoring of their cash flow and other critical financials needs. Implementing this efficient system also allowed Accenture to retire 200 legacy financial systems and gave senior executives more insights into the financials of the company.
3. What measures of success did Accenture use for this effort? Why?
• There were various KPIs that Accenture measured their success from reduction of staff to reduction of hardware. One of the main measurements was that they were able to reduce spending per employee by 60% and reduced it IT expenses as a percentage of revenue by 58%. In addition to numerical success, Accenture also measured it success by scalability of its new systems and the IT culture shifting to ROI-oriented.
1. What is the goal of having an enterprise architecture?
The goal of having an enterprise architecture is to align the business strategy with the technical capabilities of IT. The purpose is to align the business, the data, the applications and the technology so that all components can work together in an efficient manner but flexible enough to adapt to the organizations changing environment.
2. If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
By adding a new line of business, the firm needs to take into account certain requirements (systems, applications, data, etc.) and if the current enterprise architecture is working as intended, the firm may be able leverage some existing processes so that they are not duplicating efforts or integrate the new line of business into already existing processes. One of the benefits of the enterprise architecture is the current state and being able to see what you need to do to get to the future state (adding the new line of business).
3. Explain five possible ways that an enterprise architecture effort could fail?
1. Implementing Enterprise Architecture to say we’re implementing enterprise architecture. If there is no goal or purpose, the effort will fail.
2. No support from the CEO and senior management. If all leaders are not on board to provide direction and resources to implement enterprise architecture, the effort will fail.
3. No resources dedicated to implementing enterprise architecture. If you do not have dedicated resources with clearly defined roles, you do not have anyone who is accountable or responsible for leading the initiative. This team needs to have a solid understanding of the business from a business perspective and from an IT perspective. They need to be able to translate business processes into the IT proceses/systems/applications that make the data available to the business users. Without that, the effort will fail.
4. Attempting to implement enterprise architecture without a framework. Without a formal framework, the project will most likely fail because a framework for enterprise architecture would be comparable to a framework for information security; the framework is a guide of where to start, steps to follow in identifying key performance indicators, and then following through then repeating the loop to continually improve the process.
5. Silos – Enterprise Architecture needs to play nice with IT Governance and all other existing policies and procedures. The teams responsible for enterprise architecture also need to work to incorporate information security into the process, (not just information security but all key stakeholders, enterprise architecture cannot be created in a vacuum).
4. Of the four levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
Of the four levels of the Federal EA Model, I think the data reference model is the most important. The Data Reference Model (DRM) facilitates discovery of existing data holdings residing in “silos” and enables understanding the meaning of the data, how to access it, and how to leverage it to support performance results. The performance reference model is the most addressed because it required by all agencies for all IT expenditures. The Performance Reference Model (PRM) links agency strategy, internal business components, and investments, providing a means to measure the impact of those investments on strategic outcomes. It makes sense but I do not feel it is working as it was intended, it is more of a checkbox item.
Michael – the trouble with all frameworks and guidelines is that they can quickly become “checkbox items.” To avoid this you need good leadership that recognizes the importance and refuses to accept anything that well thought out and articulated.
5. Does your firm have an EA? How does it affect your day-to-day decisions?
We do not have a formal enterprise architecture at my employer. If you were looking at the stages of enterprise architecture, we would fall into the state where there are silos and business unit specific processes/data and these items are chosen sometimes with IT involvement, sometimes without IT involvement but in the end, it is IT’s job to make sure it works. Because there are many systems/processes, there are many subject matter experts but there is room to consolidate and improve these processes. Like everything else, it needs to be driven from the top to succeed.
Michael – sounds like a lot of businesses. How large is your firm (employees or revenue dollars)?
Just over $5 billion and around 700 employees. At times it feels like we have grown and are considered large for our industry but continue to run like a smaller shop.
Michael – it is surprising but perhaps its the result of many acquisitions since you said you are growing. Think of the Your Neighborhood Grocer case.
4. Of the four levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
• Business Reference Model (BRM): describes an organization through a common mission and supportive services area which promotes inter and intra organizational collaborations. Provides standards for the business and business sub-functions.
• Data and Information Reference Model (DRM): Facilitates discovery of existing data and enabling a better understanding of the data, how its accessed, and how to support it. Provides standards for data to be used and to identify opportunities for data sharing and exchange.
• Service Component Reference Model (SRM): categorization of currently systems, application and technologies that support the delivery of services. Provides the link of IT services to the business.
• Technical Reference Model (TRM): categorization of networks standards and technologies that support voice, data, video and mobile services. Provides standards for services and technologies.
Business Reference Model would be the most addressed. In any framework, I would think that the discovery of the business and business standards would be the most crucial. In my opinion understanding the business would be the baseline for any framework.
Duy – Unfortunately I think you are optimistic. I think the Technical Reference Model is often more addressed as it is easier for IT to do without business input. Don’t mistake this as a criticism of IT, all too often the business refuses to get involved with “technical stuff.”
1. What is the goal of having an enterprise architecture?
There is not one dead set of goals for having enterprise architecture. The goal of having enterprise architecture (EA) I think in simplest goal that someone would implement enterprise architecture would be to plan for the now and for the future. What I mean by this is that they need to make sure that the current infrastructure that support the business is current that it can handle whatever the user throw at it and then if sometime more is needed or changes are made that system is then easily scalable. This way you are not wasting a ton of money rebuilding from scratch by building on top on of what is currently in place in a manager that is non cumbersome and easily navigable.
2. If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
If a firm decides to add a new line of business it could affect the EA in the company because of the organization needs to understand how the new business connects into the build infrastructure and architecture. If the company for example acquires a new store that is currently operating as a separate entity there may be a lot of systems and things in place that may not work will in the current architecture or maybe a duplicate for something that already exist. Since this is the case you need to make sure you enterprise architecture is correct that way when you try and branch off it’s a seamless transition and you are not worried about making a change that could in turn cause more harm than good because you know how everything else is interconnected.
3. Explain five possible ways that an enterprise architecture effort could fail?
The first way that enterprise architecture can fail is if executive management do not take control of the architecture and make sure it is known that this is the direction the company wants to go. If they just allows their people to do whatever they want and there is no direction it will just fail due to poor implementation. Another way it could fail is because the people making decisions don’t actually know what they need in order to have a proper enterprise architecture due to lack of knowledge. Third it could fail by not properly choosing what the needs of the enterprise is and the architecture that’s around it to make it proper. Fourth it could be that something was overlook in the initial assessment. When the initial assessment was done by the team building the EA they could have over looked a vital piece that could cause them to fail. Finally it could fail due to lack of money. The company could have a bunch of good ideas but if it does not want to spend the money to implement them and cut corner it could turn a great idea into a huge problem down the road.
4. Of the four levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
I think out of the four levels of the Federal EA model the most important would the business model. I think this because it takes into account more of the administrative side of things and connects everything together. It looks at the bigger picture. However, I think the most address would be the performance model. This is because it looks at everything overall as a whole and most companies I feel would lean towards this model when they start to work on an Enterprise Architecture. I think it does make sense because this way it looks at the big picture of everything from the technology side and the business side and things and see how they work together.
Does your firm have an EA? How does it affect your day-to-day decisions?
I can’t really say for sure that we do have EA because I don’t work in IT but there there are certain procedure when new systems are put in place. I remember when there was a new AP system put in place there were multiple meeting with IT to get the system to align with the AP department needs making sure the process is accurate and bouncing ideas to make the whole process more efficient. My organization is relatively small so there no EA group but I believe this would be the business analyst people to align IT with the business.
Heiang – this sounds like normal project work rather than EA. If IT presented you with a list of two or three different AP packages saying you need to pick one of these because they fit with our architecture, you would we more likely to have an EA. It also sounds like you have a best-of-breed approach to software, otherwise you would not be implementing a separate AP package.
If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
Adding a new line of business definitely affects its enterprise architecture because there has to be a new strategies put in place for this new business line. EA will have to figure out and identify how the new business aligns with the current business. Like the last case “your Neighborhood Grocer” adding new businesses through acquisitions can be a headache because of the different moving puzzles.
1. What is the goal of having an enterprise architecture?
Enterprise architecture is more about technical capabilities needed to meet the business needs.The goal of enterprise architecture is to create a IT strategy and create a blue print of how IT could fit in to the business. Identifying whether resources are properly aligned to the agency mission. EA is also used to drive decisions about IT investment portfolio as a whole.
Heiang – don’t forget the concept of future agilty. EA is trying to match the needs of the organization in the near term WHILE maintaining the greatest flexibility to meet the technical needs of the future.
2. Explain five possible ways that an enterprise architecture effort could fail?
Enterprise architecture efforts could fail if C-level management don’t take the time to set key performance indicators for the EA team.
Also if the people involved in Enterprise architecture applies it incorrectly.
When people take it too literally and assume things have to be be done from end to end to make things successful.
If the people are not experienced or don’t have the expertise to implement the enterprise architecture.
When IT and business goals are not aligned and EA Governance is not established.
3. Of the four levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
The most important Federal EA model to me would be the business reference model because it is the base of everything. It describes the organization through a common mission. It also provide standards for the business and the sub-functions. All the other model come afterward because you need to know the mission before anything else happens. The most addressed would be the technical reference model because it’s easier to just deal with the technical part instead of getting other people in the organization involved.
What is the goal of having an enterprise architecture?
The goal EA is to better align technical processes with business needs. It can reduce the complexity associated with digital transformations by having a high level and holistic view of the entire enterprise itself. The purpose is to optimize the enterprise and business functions that could potentially be fragmented and misaligned with technology. It is a function that will improve the long term performance of an enterprise.
Of the four levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
From the readings it would appear there are actually 5 levels of the Federal EA Model.
The Performance Reference Model supports architectural analysis as a function of performance. It describes the quality of technology in the overall organization or agency.
The Business Reference Model gives a business view of the various functions of the organization as whole. It combines the business and service components of an organization. It describes the organization as a whole as opposed to a silo organizational view.
The Data Reference Model facilitates discovery of existing data holdings residing in segments and enables understanding of the meaning of data, how to access it, an dhow to leverage it to support the organization.
The Technical Reference Model or Application reference model is the software providing functionality for the organization
The Components or Infrastructure Model is the hardware providing functionality that enable the delivery of voice, data, video etc for the organization.
My guess is that the performance reference model is the most importance because it outlines the cross and intra agency goals and objectives. This will serve as an outline and foundation for all other levels.
The application reference model is probably the most frequently used as it will help build scale by allowing agencies to reuse common solutions.
Overall the frame work makes since. There are defined goals, checks and balance, and support systems in place to maximize results.
Thank you for this, Paul. I also found reference to five models, so I was unsure if I was losing my mind at first. Adding to your reference to the PRM, that model also matters because it provides the guidance on how to get the inputs of people, tech and other fixed assets to flow, via processes, to business goals and needs of the customer/client/agency as you mentioned. By identifying your goals and giving a structure for how to get your inputs to them, the PRM would remain a crucial guiding force as a firm/agency works its way through the other reference models.
If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
The firm would first need a solid understanding of their EA specifically the various building blocks and how they are integrated into the various units. If a new line of business can fit seamlessly into the current foundation than there might not need to be a lot of work. However if the new line is not going to fit seamlessly with the guiding principles that direct the current building blocks and the interrelationships they have then more work will need to be done. It is important that there is a standard throughout the EA and that all lines of business have the same strategic objective. A new line of business may need to me manipulated and integrated to confirm the same strategic objective.
Five possible ways an EA effort could fail
1. There might not be a clear and defining performance plan in place. If there is nothing built in to monitor performance it would be difficult to know if they are on moving in the right direction
2. If the lines of business are fragmented and don’t have the same strategic objectives an EA effort would fail. The various business units and overall strategic objective all need to be aligned to insure success
3. Again if the business units are fragmented than information will not be shared. It is important that all units can access and leverage information to support the performance of the individual units. If one unit withholds access than other units will not function at a high level
4. If the overall infrastructure is not well though out with the enterprise strategic objective in mind than it will inhibit productivity. It is important that individual business units can navigate the enterprise efficiently
5. If there is no upper management support than the EA will fail. It is important to receive buy in and support from upper management so that they can funnel throughout the rest of the organization.
1. What is the goal of having an enterprise architecture?
Our CISA review manual describes EA as the process in which it “encompasses documenting an organization’s IT assets in a structured manner to facilitate understanding, management, and planning for IT investments. An EA often involves both current state and optimized future state representation (i.e., a roadmap)”. Enterprise Architecture will translate an organization’s strategy by recognizing and evaluating the ECM and comparing it to the desired business vision and outcomes. Therefore, the goal of EA is to connect the gaps between IT and the business which will, in turn, assist the company in being more efficient in servicing their customer base and increase their success.
5. Does your firm have an EA? How does it affect your day-to-day decisions?
Yes, I believe we do. Before our Banner implementation, we used the ISIS system, which at the time of my arrival was already antiquated. I can recall hearing the phrase our departmental operations team always patching the system to accommodate our functional needs. We seemed to always work in a reactive mood apposed to being proactive. However, a few years ago the University decided to overhaul of systems in their entirety. I do mean systems… If I can recall each department (i.e., HR, Finance, Computer Services, etc.) correctly all worked in a different system outside of ISIS. Nevertheless, there was a larger undertaking in progress, and I believe Zachman statement describes it best when discussing IT taxonomy within the building industry “Architectural artifacts are implicitly organized using a two-dimensional organization. One dimension is the various “players in the game.” For a physical building, some of these players are the owners (who is paying for the project), the builders (who is coordinating the overall construction), and a zoning board (who is ensuring that construction follows local building regulations).”
1. Enterprise Architecture is an integrated blueprint of the enterprise that describes the structure and operation of an organization. From an IT perspective, its purpose is to ensure that the IT infrastructure and its usage is aligned with business requirements.
2. A new line of business might cause a company to have to restructure its enterprise architecture to ensure any future IT projects are aligned with the goals of the new service. Prior to implementation, the organization should make sure that it’s enterprise architecture is structured in a way to include the business needs of this new service. The amount of restructuring depends on how different this new line is to its current services.
3. 5 ways enterprise architectures can fail are:
1. Lack of support from top executives
2. Developing an architecture that is too technical and difficult to understand
3. Developing an architecture that is inflexible and reliant on one framework or tool
4. Developing an architecture that is not integrated with the needs of the business
5. Unrealistic expectations, the architecture must be developed to organize an organizations existing capability.
4. Of the four levels of the Federal EA model I feel the most important is Level I since this is the level that defines the Architecture Drivers, Standards, Process and Strategic direction. If any of these are inaccurate, the EA is at serious of failure. It appears in the framework level IV is the most addressed. This makes since because this is the level in which the architecture becomes more explicit and includes the data, applications, and technology that will be developed in the organization.
5. I am unaware of an enterprise architecture at my current employer. Many projects seem ad hoc and the implementation of new software is unorganized. It seems that the design and implementation of an effective Enterprise Architecture would be a benefit to my current employer.
Accenture Case Study Question Responses:
1. What is Accenture’s core IT philosophy?
Accenture’s core IT philosophy is that it followed a decentralized approach where specific organizations managed and ran its own systems and applications based on location. This method created havoc for the company because outdated software systems caused an inability to access key systems and databases remotely through the internet and required extremely large and expansive private networks. Accenture followed the structure that their predecessor, Arthur Anderson, where the core idea of an IT philosophy was that IT is a cost center with an assigned budget, run by technology-savvy engineers with not too much involvement from management. It is the typical structure that larger businesses follow. The way the budget was allocated was based on who had the highest rank and the loudest voice, with a line starting until there was no money left. This practice causes key projects to be skipped over, causing IT to focus solely on one person’s agenda and creating large gaps in technological advancements. It also causes the company to be disconnected with one another, creating great communication and data gaps.
2. Identify three key IT projects from the 2001 – 2008 period and explain how each strengthened Accenture’s enterprise architecture?
A key project that Accenture underwent was decommissioning applications and seeking to work with a single vendor for application distribution. They chose Microsoft for this task. Through this, Accenture was able to strengthen its enterprise architecture because engineers were now all using the same platform to run their tasks on and were able to create a more compatible system. This also creates an environment that reduces the overall expenditures as well as providing the company an option for growth. The largest strength piece was shown through the cost reduction because extra funds allowed for additional IT projects while also integrating the company as one. Next, Accenture restructured its business model to run IT like a business. Through this, the enterprise structure was strengthened because engineers became more like product managers, who were able to design unique products that they could offer and focused on innovating around a particular area. Lastly, a new governance structure was implemented to administer all IT decisions. This strengthened the enterprise architecture because it created an integrated business where key IT decisions where reviewed and decided to move forward based on value to the business and how it would complement other initiatives.
3. What measures of success did Accenture use for this effort? Why?
A key measure of success that Accenture was able to use to measure the effort was the large reduction of costs over the changing IT initiatives. With the cost reduction in place, the IT budget was able to be heavily expanded and new and additional projects were able to be implemented, thus appeasing more employees and clients. Another method of measuring success was implementing the ROI method when evaluating projects. Through this, the loudest and highest ranked people were not considered but the company was able to see how the money actually went to work and how additional revenue and growth could be obtained for the organization.
Accenture Case Study Questions:
1. What is Accenture’s core IT philosophy?
Accenture’s core IT philosophy is that it followed a decentralized approach where specific organizations managed and ran its own systems and applications based on location. This method created havoc for the company because outdated software systems caused an inability to access key systems and databases remotely through the internet and required extremely large and expansive private networks. Accenture followed the structure that their predecessor, Arthur Anderson, where the core idea of an IT philosophy was that IT is a cost center with an assigned budget, run by technology-savvy engineers with not too much involvement from management. It is the typical structure that larger businesses follow. The way the budget was allocated was based on who had the highest rank and the loudest voice, with a line starting until there was no money left. This practice causes key projects to be skipped over, causing IT to focus solely on one person’s agenda and creating large gaps in technological advancements. It also causes the company to be disconnected with one another, creating great communication and data gaps.
2. Identify three key IT projects from the 2001 – 2008 period and explain how each strengthened Accenture’s enterprise architecture?
A key project that Accenture underwent was decommissioning applications and seeking to work with a single vendor for application distribution. They chose Microsoft for this task. Through this, Accenture was able to strengthen its enterprise architecture because engineers were now all using the same platform to run their tasks on and were able to create a more compatible system. This also creates an environment that reduces the overall expenditures as well as providing the company an option for growth. The largest strength piece was shown through the cost reduction because extra funds allowed for additional IT projects while also integrating the company as one. Next, Accenture restructured its business model to run IT like a business. Through this, the enterprise structure was strengthened because engineers became more like product managers, who were able to design unique products that they could offer and focused on innovating around a particular area. Lastly, a new governance structure was implemented to administer all IT decisions. This strengthened the enterprise architecture because it created an integrated business where key IT decisions where reviewed and decided to move forward based on value to the business and how it would complement other initiatives.
3. What measures of success did Accenture use for this effort? Why?
A key measure of success that Accenture was able to use to measure the effort was the large reduction of costs over the changing IT initiatives. With the cost reduction in place, the IT budget was able to be heavily expanded and new and additional projects were able to be implemented, thus appeasing more employees and clients. Another method of measuring success was implementing the ROI method when evaluating projects. Through this, the loudest and highest ranked people were not considered but the company was able to see how the money actually went to work and how additional revenue and growth could be obtained for the organization.
3. Explain five possible ways that an enterprise architecture effort could fail?
The five possible ways that an EA could fail would be:
◊ Failure to engage the people within the organization.
◊ The stakeholders are not invested nor do they have a full understanding.
◊ IT does not communicate or measure the impact to the organization.
◊ Not Spending Enough Time on Communications
◊ Failing to create an effective EA governance parallel with the content and process
In my experience, I’ve seen the first four happen several times. It’s most common where an impact is missed and then uncovered later on or uncovered right before the deadline and then the impacted team needs to scramble around trying to make necessary changes or the project gets pushed back.
It would certainly seem as though my company does not have an enterprise architect in force. I am not defending my organization but there are very unique systems and technology requirements throughout the organization. There are probably 5 large technology platforms utilized throughout the organization. Within each technology platform I would venture to guess that there is a project overseer that aligns business strategy with technology but integrating the individual platforms likely wouldn’t make since as the building blocks would all be different. This is not uncommon in the insurance indusrty and I have seen it this way for 3 different companies. Generally speaking the insurance industry is very slow to accept technology integration which is disappointing.
Good points Paul. I think insurance seems like one of those industries where there doesn’t seem like there is a lot of room to use cutting edge technology or the opportunities to use cutting edge technology does not justify the risk to the business or the data. I have read about artificial intelligence being a huge game changer in the insurance industry with the potential to reduce claim filing times and significantly reduce fraudulent claims. It will be interesting to see where it ends up going.
4. Of the four levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
In reviewing the CISA review manual I believe I identified five FEA reference models, which are,
performance, business, services technical, and data reference models. The technical reference is most addressed, but I also believe the that the business reference model is equally important. CISA describes each model as:
1. Performance reference model is described as an outline that calculates IT investments and performance and their contributory factor to the platform.
2. Business reference model is a framework that defines the roles, and sub roles executed by the government, outside of the organizations that do them.
3. Service component reference model a function no framework that clarifies the service component that supports business and performance objectives
4. Technical reference model explains the role technology will play in “supporting the delivery, exchange, and construction of service components”
5. Data reference model defines the data and information that will support both the business line operations and the program.
2. If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
During the EA review/implementation the organization would have mapped out their goals and long-term strategies, therefore the handling of a new line of business should have been relevant during their initial assessment. Nevertheless, the effects of adding a new line would need to be measured, as it relates to cost, risk, and resources. If not, the new line of business could drastically affect the organizational goals, as well as IT.
1. What is Accenture’s core IT philosophy?
• At the beginning Accenture iT philosophy was that IT was a cost center. IT was soloed each office had their own software application that need a specialized staff to operate.which cost the company a lot of money to maintain. Their new IT philosophy was to make IT as a business within a business instead of a cost center. IT was driven by the needs of the internal customers and stakeholder. They needed to set a standard to be able sell to the customers because they were consulting on the things that their own company had issues with. They were able to use themselves as a proof of concept for their clients
2. Identify three key IT projects from the 2001 – 2008 period and explain how each strengthened Accenture’s enterprise architecture?
They were able to select a platform using a one platform approach. They chose Microsoft for their infrastructure and SAP for their software. This created a seamless flow of information and also lowered IT support head count because they didn’t need multiple people to specialize in their multiple applications anymore.They put together a new IT governance with the better processes like sponsored analysis. They were able categorize and defined services. Also having benchmarks for service allowed them to outsource some of their services.
1. What is the goal of having an enterprise architecture?
The goal of having an enterprise architecture is to ensure a companywide integration. It allows the use of multiple systems and applications to be compiled together to create an improved efficiency system. It allows a user to run an application that will achieve specific data by setting up the IT landscape as to ensure developers are always able to go make additions and improvements without destroying a previously made connection. By having a project architecture team, the enterprise landscape can be developed to ensure that designs are set and ready for future development and improvement while ensuring a key integration of systems.
2. If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
When a firm chooses to add a new line of business, its enterprise architecture might be affected by new systems and applications that may come in to play. By adding new systems and new applications, the firm may have to adjust the architecture to ensure these areas are included in their generated reports and compilations of data. For example, a retail bank decides to merge with an investment bank to create one large organization. Through this, each business unit uses completely separate systems and applications but want to target the same clients to use their entire organization rather than aspects of it. When compiling data, it would be useful to have access to a customer on both sides of the business by using one application and report compared to multiple systems and applications.
3. Explain five possible ways that an enterprise architecture effort could fail?
The first possible way that an enterprise architecture can fail is due to a lack of reasoning or business case for initially implementing the enterprise architecture to the business. Without a cause or reason, employees will struggle or not care to hop on board the idea, thus causing it to quickly crash and burn. Next, an enterprise architecture can fail due to a lack of support from upper management and the CEO. By not having key organizational leaders on board with a business initiative, it will not be taken seriously and the protest of it will cause lower end employees to avoid pursuing the idea to focus on the goals and initiatives that they will be recognized for. Another way an enterprise architecture can fail is through a lack of resources being allocated to ensure the success of the implementation project. Without specific resources and an assignment of employees to implement the project, people will do so at their own leisure and the project will not be completed in a timely manner, causing it to lose support from the firm. Another cause of failure would be a lack of communication about the project from managers to engineers. By losing a communication about how the platform should be set up and managed, people will lose focus and the project will become filled with havoc and set on a path to failure. Lastly, an enterprise architecture project can fail due to a poor selection of architects for the project. With a poor set up and design, employees will quickly become frustrated with the system and refuse to use it, preferring the more complex methods because they are more comfortable with them, thus deeming the new system useless and ineffective.
4. Of the six levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
Of the six levels of the Federal EA, I feel that Data Reference Model (DRM) is the most important of the Federal EA levels. Through this, a organization is able to ensure the standardization of its data and allow for the creation and expansion of data of its network as it becomes integrated. I feel that the ARM and IRM are important to ensure that the system is able to properly function but the DRM is what makes the system itself begin to become useful to the organization rather than simply being another added system.
5. Does your firm have an EA? How does it affect your day-to-day decisions?
The firm that I work at does have an EA in place. Working in audit, it is crucial to have an EA system in place because it ensures the entirely company is integrated and we can compile data from multiple sectors using our own system with one single application. It affects day to day decisions in that I can compile data quickly from multiple areas and systems that I am unfamiliar with to ensure the organization is adhering to policy and company framework. An issue with the EA in place is a lack of employee support, driving down a desire to use the EA but still utilizing it due to an understanding of its usefulness.
3. What measures of success did Accenture use for this effort? Why? Accenture had multiple measures of success like ROI projections and performing post-implementation audits to make sure it delivered the value it promised. Also they were able to measure it financially because spending went down tremendously. IT overall expenses as part of net revenue by 58 percent.
1. What is the goal of having an enterprise architecture?
The main goal of enterprise architecture is to achieve a unified IT environment across the organization. EA focuses on supporting the strategic changes and promoting alignment and standardization across the IT and business environments.
2. If a firm decides to add a new line of business, how might it affect its enterprise architecture? Explain?
If a firm adds a new line of business, its enterprise architecture will surely be affected. The EA will need to be modified to align with the new business strategy and goals. The new line of business bring most likely bring new systems and applications, therefore changing the priorities and responsibilities of the IT department. Adding a new line of business may not mean that EA will need a complete overhaul, but slight modifications will definitely need to be made to accommodate those changes.
Explain five possible ways that an enterprise architecture effort could fail?
– Lack of sponsorship/support – EA can only be successful if there is buy-in from management.
-Too much focus on IT – Focusing too much on IT does not necessarily lead to a good strategy to implement EA. If a company fails to align its IT strategy with its business strategy, EA will not be effective or successful
-Lack of skilled personnel – Not having the right skillset could lead to wasted resources, over budget and missing project timelines
-Lack of flexibility – If the EA is not designed to be flexible and evolve to accommodate future changes in technology, it could lead to expensive and obsolete hardware and applications
-Lack of governance – Failing to establish a culture or tone at the top
4. Of the six levels of the Federal EA model which do you think is most important? Which is most addressed? Does this make sense to you?
The Performance Reference Model is the most important and most addressed. THis makes sense, as successful EA in an organization must have the right tone at the top. Instead of the guidelines becoming just another item to check off the list, the Performance Reference Model (PRM) facilitates collaboration between business, strategy, investments and provides a means to measure the impacts of the investments
5. Does your firm have an EA? How does it affect your day-to-day decisions?
Short answer, yes. We have EA and put a lot of focus on it. As an extremely large firm with very complex applications and systems all working together, it is essential that we place this large focus on EA. We have highly skilled and experienced architects in my LoB and spend a lot of time planning for the current and future states of our IT.
As far as affecting our day-to-day decisions, maybe I’ve just become too used to it to notice how it affects my decisions. It affects the way we think about and design our projects. We must keep in mind the current limitations of our architecture as well as planning the projects for the future state so we don’t have to go back and redesign year after year.