Todd Biske: Outside the Box

I’ve been doing some work recently on architecture principles and their associated implications. According to TOGAF 9’s documentation on architecture principles, implications “should highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs, and activities/tasks. … The impact to the business and consequences of adopting a principle should be clearly stated.”

In the effort to define our implications, I’ve started to see two categories of implications emerge. The first is behavioral implications. These implications are functions or processes that the organization must adopt. The second is architecture/design implications. To illustrate this, use a very simple principle: standards-based. The statement for this principle merely states that all solutions must be compliant with company standards. A behavioral implications for this is that someone in the company must maintain a list of company standards. Another behavioral standard may be that the company must follow the work of standards organizations relevant to the business. An architecture/design implication would be that messaging interfaces must adhere to published company standards.

I’m finding that it may be worthwhile to explicitly define these categories in documenting the principles. One big reason is to avoid overemphasizing the architecture/design implications. It is very easy to strictly think of implications as the foundation for your assessment framework, but an assessment framework, in my experience, is typically associated with architecture and design reviews. It says nothing about reviewing the behavior of the organization, which all too frequently can be the greater challenge. For example, a reusable service may exist, but it doesn’t get used because the organization “supporting” it may see supporting other consumers as a secondary priority, at best. This isn’t a design issue, it’s a behavioral issue.

One additional thing I’m also considering is how to assess whether or not the thinking behind the implications is correct. If the rationale for a principle is that total cost of ownership will be lower, are we actually measuring whether this winds up being the case based upon our level of adherence to principles and their implications?

How would you categorize your implications? Does this two category breakdown make sense, or are there additional categories needed?

In her IT Business Edge blog titled Enterprise Architecture Paying off at Del Monte, Loraine Lawson writes:

Enterprise architecture (EA) befuddles me. As far as I can ascertain, it began as an IT function, but at some point, it was decided that EA is bigger than IT and really needs to work with the business as a business function. … I’ve had my doubts about EA, even though I’ve written several times about how the discipline can reduce integration work.

I thought I’d respond to these statements from the blog. First, regarding the thought that EA is bigger than IT. While some may argue that the original definition was always about more than IT, it’s certainly true that in practice, the focus was almost always within IT. The reason, however, that it needs to become more of a business function is that IT needs to be a business function, rather than being simply viewed as a support organization where things are thrown over the wall. This is also exactly the reason why Enterprise Architecture is a necessary function.

In a pure support scenario, you do what the customer asks, period. You can try to sway the customer, but that’s a risky proposition. Everything is constrained by the definition of the project. In such a culture, decisions that may be beneficial when viewed from the perspective of multiple projects and multiple systems are extremely difficult to make, because they are outside of the control structure (the project) that governs all of the IT activities.

Coming back to Enterprise Architecture, part of the reason it needs to be viewed as a business activity is to change the decision making process around how IT activities are defined. If this process doesn’t change, then IT can only make the best of the hand it has been dealt. Low level technology decisions, such as servers, operating systems, and programming languages, can be handled solely within IT, but as soon as you get into functionality and capabilities, it becomes far more difficult.

In my opinion, the way to do this is through a practice of portfolio management, which I believe needs to be at the core of an enterprise architecture practice. Portfolio management isn’t a one time application rationalization effort, it’s an ongoing discipline that must be integrated into the decision making process for what activities (projects) take place. I’m not referring to project portfolio management, I’m referring to application portfolio management and technology portfolio management. If we do an effective job of this, we better understand the boundaries and dependencies between the capabilities that need to be provided. By better understanding these, the task of integration becomes easier, because it’s a forethought rather than an afterthought.

It’s surprising that this focus on application and technology portfolio management is such a struggle. After all, concepts of portfolio management are well accepted in the financial world. It is a far more risky venture to just blindly purchase financial products that hot today, rather than taking a structured view of your entire investment portfolio and the goals you wish to achieve. But, alas, IT is a very project-driven culture in most organizations, and it is going to take time to change that. Many organizations have reached a breaking point where a one-time application rationalization effort is taken. If your organization is in this position, however, a one-time effort is only a short term fix. Business leaders must not only fix the current situation but also make the necessary changes to ensure it is does not happen again, and I believe a healthy enterprise architecture practice rooted in a disciple of portfolio management is one of those changes needed.

Panel discussion. Panelists:
Eric Christian, Director of Global Architecture Security at Cummins
Sandy McCoy, Executive Director, Business Architecture, Kaiser Permanente
Michael Balay, AVP, Technology & Operations, Enterprise Architecture, MetLife
Moderator: George Paras

Q: Inspiring an EA team is a challenging activity. If you had one bit of advice to an aspiring EA leader, what would it be?
Sandy: There’s an outward leadership component and an inward leadership component. From the outward perspective, anyone on the team must be a leader. You operate at levels most people don’t. Emotional IQ important, and you have to be able to communicate both with a developer or project manager at one time and the CIO the next. From the inward perspective, your people must be empowered and encouraged. EA is a thankless job, you must know when your staff is having a bad day.
Eric: We have a tremendous opportunity to add value. Focus on delivering it incrementally. Focus on delivering high value in a way that the business community can embrace.
Michael: Leadership matters in every aspect of business, especially for the EA organization. Every staff member must be a leader. One of the most important things to do at each stage of transforming is to find leaders to partner with elsewhere in the organization.

Q: As a leader, when you’re looking to incrementally grow your team, what skills do you look for?
Michael: It’s about a team and having a balance of skills. I look for people with both operational and architecture skills.
Sandy: We have a minimum of 15 years of experience, through various tracks within IT to have a variation in the skill set. When you start getting into business architecture, some business acumen is becoming more and more critical. Technology is just built into the business, we are part of the DNA.
Eric: Strongest architects as of late have knowledge of the business. It’s easier to teach an architect to be an architect than to teach them the business in a particular industry.

Q: Where do architects with business acumen come from?
Eric: At Cummins, we have been looking at horizontal immersion programs. They take a horizontal assignment within the business and will hopefully come back. The same holds true for business staff to take a position within IT for a while.
Michael: The balance is going to shift toward more business architects. I always want that business architect side by side with someone who understands the implementation, though. My bias is to find business people, match them up with someone from IT, and let them learn from each other.
Sandy: One skill that I would add to the list is abstract thinking. If you have people that can really think abstractly and connect the dots, then their actual experience is not as critical. Not everyone has this ability.

Q: What size team do you look for?
Sandy: Our chief architect likes to re-organize every 6 months, but his boss tells him to stay stable for a year. You have to adjust to whatever is happening at the time. You need to have a bunch of utility players as well as some heavy hitters in particular areas.

Q: What are the best practices to organization a team?
Eric: Cummins, a couple of years ago had a very decentralized IT. Three years ago, IT was centralized, as where the architects. We have largely aligned along Technology Architecture, Solution Architecture, Enterprise Architecture.
Architecture is an evolution, a maturity process. When you move toward the block and tackle approach, you start with fundamentals (doing well with infrastructure architecture), but as you move up you look at portfolio optimization, etc.
Michael: There is no one model for EA. Almost by definition, it must be designed and tailored to the circumstances of the enterprise. Collaborate with other leaders. Enterprise Architecture must be responding to the strategic events of the company, and may not be able to steadily climb that maturity curve. Groups that do, may be too inwardly focused.
Sandy:If you look at it as a role, rather than an organization, very rarely do we play the role of an Enterprise Architecture. As EA, we can play any of the roles, and we get pulled down into various levels of the architecture depending on the needs of the organization.

Q: How do architects split their time between strategic and tactical work?
Michael: A peer of mine worked on a very successful, strategic architecture for technology integration and services. This year, he’s continuing the effort, but driving down into the implementation of it. At different periods we need different skills.
Michael: This is how things worked at Cummins a year ago. Each of the architects focused on quite a bit. They became spread to thin, weren’t focused on the right things, and the value was marginalized. We made a separation between solution architecture and enterprise architecture to create focus on both areas, and this yielded far more traction.
Sandy: It depends how your mission statement is defined. We have 13 different divisions and they each have a different opinion on what we should be, plus the CIO has another opinion. Set some metrics on what you’d like to do.
Michael: We’re struggling with refocusing. There are too many strategic things out there.
Eric: One of the first things that was negotiated with my boss was the vision and mission. That became the contract. If business partners think something else, we come back to the contract.

Q: How do you demonstrate the value of your EA program? How do you make the investment decision for a tool like Troux?
Michael: We implemented Troux standards in 2-3 months. We were re-instantiating AIG standards. We didn’t have to reinvent the standards, but we did need to reach out to the international community. Traditionally, the review process came very late in the effort. We worked with the PMO to push up the visibility of the project to early in the process, especially so EA had visibility. If managers got involved early, 9 times out of 10, the went through the process very smoothly. We turned the traffic cop into a value proposition.
Eric: We have seen value delivered in a body of analysis work that we have done. Most things have Oracle under the covers. We had our best year ever with an excellent growth trajectory. The value comes into play with trying to balance continued growth of new plants with a strategy for managing the instances of Oracle apps.

Q: What should our audience be paying attention to?
Sandy: Social networking and mobility. People who grew up with it, want and expect collaboration. On the mobility side, everyone wants a little “app” for a piece of the business. Information and data governance becomes much more critical because it is now exposed in places where you may not want it to be.
Eric: Server, app, and desktop virtualization, mobile technology, and SaaS and cloud.
Michael: Mobility, BYOD – bring your own device, Collaboration systems on a new scale, IaaS and virtualization. In the governance space, issue is that we’re already too slow for our customers.

Speaker: Michael Pemberton, Enterprise Architect and USAA

USAA has had an enterprise architecture practice on the technology side and is now establishing a business architecture practice.

First point: Why did USAA take the journey? They realized that without a business-driven, integrated enterprise architecture, it would be like driving without a map.

Their challenge was that they are trying to increase their revenue and the membership, but at the same time, reduce their operating ratio. They needed to reduce the complexity and operating friction within the organization.

For them, being too close to the Enterprise Strategy team was a problem for their Enterprise Architecture team. It may seem counterintuitive, but there are some pressures to keep the strategy team “clean” while the Enterprise Architecture team needed to be out there working with the community.

Models need to be designed to answer questions. The business doesn’t care about the components and representation in the model, they care about the answer to the question they asked. They aim to create visualizations for the enterprise.

USAA Opportunities and Challenges:

• No metamodel, no design!
• Architect architecture
• Business focused architecture
• Visualizations, visualizations, visualizations
• Roadmap capabilities
• Killer curves: supply/demand

They showed a visualization which was essentially a spoked wheel with member at the center of the universe. A layer out from the member was a set of capabilities, then another decomposition to the business level, and then finally a set of processes out in the business. They found the normal “box-in-box” capability view to be unwieldy for the number of capabilities they had.

They also made a commitment to never come to the business with a single taxonomy again. They needed a single taxonomy to do their work, but the business needed to see the results in their own language and taxonomies. They create taxonomy alignment, but they don’t force a single taxonomy on the entire organization.

Principles they use for their visualizations are:

• Use graphics, not words (look up InfoGraphics)
• Show context and meaning NOT context and conclusion
• Enlightenment NOT training
• if you ever show the business your model, you deserve whatever you get – and it won’t be pleasant
• Quit telling executives they should use the tool!

This was a continuation of the previous panel discussion. Speakers were:
Sean Dwyer, Northwestern Mutual
Jennifer Pfaff, Jacobs Engineering
J-P Renaud, Jacobs Engineering
Eivind Nilson, Liberty Mutual
Moderator: Chuck Keffer, Troux

Q: Where are you in rolling out your current effort?
Sean: They are trying to roll out the ability to do assessments of infrastructure, roadmaps, and then send out a system feed to the governance organization. Their goal is to only have to enter information in one place.
J-P: They are rolling out Application Optimization right now, then Alignment, then Standardization. A lot of customers at the conference do Standardization first, others indicated Alignment might be the best place to start, but for them, Optimization gave them the immediate tangible benefits they needed and put in their business case.
Eivind: They also started with Optimization and a bit of Alignment. The questions they were trying to answer led us to those two modules as opposed to Standards. They went through the data gathering process and have pretty much completed it, however there are always new things they are finding. They are about to roll out a workshop where they bring stewards into the conversation not just as the data entry point, but as data consumers in their decision making process. They are establishing an advisory board with IT and business representation.

Q: Change management is a key part of your strategy. Can you talk about a few of the most important considerations underlying your approach?
Sean: This is a lifestyle change. If you don’t embrace this and get people to feel good about it, you’re dead. They had a change management communications lead assigned to the project that assisted them in their effort. They focus on baby steps, going for the single rather than the grand slam. They also chose not to start with Alignment. If you screw up within IT, people understand what you were trying to do and are more forgiving. If you screw up with your partners/sponsors that don’t have that solid understanding, the risks are greater.

Q: What concrete steps are you taking to keep the data current, correct, and complete?
Jennifer: They are adding more data stewards, having a first governance meeting soon, and establishing the processes.
J-P: They are taking a hierarchical approach to their data steward for more effective management and allowing individuals to only have a small set of data for which they are responsible. People also have a vested interest in keeping the data current.

Q: What are the target accomplishments that you are working toward?
Eivind: They are trying to speak in terms that are meaningful to their stakeholders. They positioned their data around some simple ideas. First, a summary view of the applications that are target versus non-target for rationalization, including which ones have a specific retirement date. The ones that don’t add up to some amount of dollars. This was the potential savings opportunity by IT owner. They took the same data by business owner to show the financial opportunity available. This seems to resonate very well with the people who have seen it. They also have a report that shows planned retirement by quarter. If there’s not much from your area, someone will ask why. They are documenting the dependencies and the reasoning behind their determination of target versus non-target.

Q: In launching your initiatives, did you leverage any EA framework?
Sean: No. It was more of a cultural thing.
J-P and Jennifer: No, but they did read Enterprise Architecture as Strategy and started there.
Eivind: They did use a standard business capability model for our industry, but tailored some of the language to make it specific to their company.

Q: Did you leverage any tools like stakeholder maps to obtain buy-in?
Sean: In the roadmapping effort they reached out to department heads and IT leaders and asked them what roadmap meant to them and what value they would get out of it.
Eivind: They just tried to make it as simple as possible.

Q: How does one measure success of an EA initiative and do it in a repeatable way?
J-P: Success was when we hit the ROI goal in the business case. Once past that, everything becomes easier. They are focused on that initial program and the ROI associated with it.
Sean: They have three year plans and divisional metrics. They measure how much they save through cost avoidance and reuse.
Eivind: They measure how many applications have been retired. They are still identifying targets and getting them on a roadmap.

This was a panel discussion, consisting of:
Sean Dwyer, Northwestern Mutual
Jennifer Pfaff, Jacobs Engineering
J-P Renaud, Jacobs Engineering
Eivind Nilson, Liberty Mutual
Moderator: Chuck Keffer, Troux

Context: Today’s reality for the global 2000 CIO. The average tenure is 18 months. They need to get started fast and work fast. They face shrinking budgets, rising expectations, and a big focus on alignment with the business.

The average annual sales of a global 2000 company is around $15 billion, and on average, 4% of that goes to IT, yielding $600 million for discretionary spend. Unfortunately, 80% of that may be spent on keeping the lights on, and another 80% is already allocated to business driven IT efforts, leaving $24 million or less for the CIO that is truly discretionary.

Chuck then went into Troux’s question driven approach for driving business value out of EA. It’s focused on the questions that EA stakeholders are asking, and the decisions they need to make.

Q: What were the top three factors and/or considerations in building the business case for your 2011/2012 initiatives?
Sean: In 2010, they did a lot of pilot work in the APM space. They did some charts and graphs to show that they could add value. He built the “mother of all spreadsheets” to support this pilot work whose support could have been a full-time job. They made the decision to pursue tooling to support this, rather than the “Microsoft” stack. They then tried to align themselves with the IT business strategy, such as “simplifying the business technology environment.” It was going to be difficult to this without a robust portfolio management system.
Jennifer: They had a number of objectives. They wanted to maintain sustainability, improve business alignment, improve the IT planning and systems responsiveness. On sustainability, they wanted to avoid inventing the wheel and creating processes that would increase the amount of work they had to do. They wanted to simplify things.
J-P: He re-emphasized the sustainability point. They wanted to “operationalize” the data gathering exercise. There’s a big effort that goes into the initial data population and they wanted to make sure they had processes to keep it up to date without adding huge effort to the organization. They tried to rely on places where the information was already being entered, rather than adding a new step to existing processes.
Eiving: First, they needed a practice around application portfolio rationalization, and then had to do the rationalization itself. The insurance industry doesn’t have a tangible product, it’s a promise. Their systems are the products, then. Through acquisitions, it is painful for the business to have their products in multiple suites of insurance systems. Rationalization had to happen. They are also highly regulated at the state level and a significant effort is required to maintain compliance on every one of the systems. This impacts their agility. Second, once the team was formed, they looking into tooling, including sustainability, operationalization, and business alignment. They wanted to be able to engage the business in the problem solving in defining what the target state was.

Q: Who did you have to convince to sponsor the effort? What were their motivations?
Sean: They made a difference between commitment and motivation. They had to work with the CIO and the IT division leaders. When they did these things, it was a lifestyle change for IT. It breaks down silos and you need communication and org change to support it. They took a baby step approach, not going enterprise wide. They focused on supporting IT first, before ever going out to the business.

Q: What role did ROI play in the business case?
J-P: ROI was the business case. They don’t sell a product, they sell man-hours. Our profit margin is on the order of supermarkets. They got the ROI specifically on the application optimization piece. It was the easiest one to get hard dollars out of quickly. EA is hard to define, we used the ROI calculator, cut the value in half twice due to company conservative culture, and kept doing this until they had a value that they were comfortable making a commitment to.
Jennifer: Work with the culture in your company. You may not have to cut down the numbers as much as we did. They used Forrester data to help support their case, and ultimately, it was easy to stand behind.

Q: What was the biggest challenge you faced in building/communicating the business case?
Eivind: They felt it was important to get stewardship of the data close to the IT owners. They had to show the value to those people because they would have to commit resources to do the stewardship function. They partnered with one of those organizations and did a proof on concept with a subset of that organizations portfolio and demonstrated the reporting capabilities. That gave them a champion. It is an ongoing thing to keep that commitment, those groups have other priorities that don’t go away.

Q: How much was the business case for technology a part of your business case and what was the underlying argument for it?
Sean: Technology was a big part of it. If they wanted to have better capabilities and enhance our agility, they needed better tooling. If they hadn’t done the pilot work, however, they would not have been successful. Those pilots and POCs generated a lot of good will.

Q: What techniques did you employ in communication the business case?
J-P: They did not have to sell EA. They had a CIO come in that had previous experience with EA, who kicked off the effort to establish the practice, spending a year figuring out what it needed to be. They reached a point with EVP (Excel/Visio/Powerpoint). They generated a list of things they can do and the frequency they could have updated it with their availability with the EVP approach, and then talked about what they could provide with better tooling and did the build versus buy analysis.

Q: How involved were the beneficiaries/stakeholders in making the business case?
Eivind: He mentioned their POC and the use of the “champion” to help establish credibility. They also reached out the corporate business planning and strategy group, and got representation from them in the effort. This went a long ways to helping things out.

This presentation was given by Richard J. Reese, VP of Enterprise Architecture for Discover Financial Services.

He started by showing some of the Discover “Peggy” commercials (look them up on YouTube, they’re pretty funny) and emphasized that Discover is known for their cash back programs and their customer service.

EA resource allocation at Discover is 35% solution architecture, 24% on governance, standards and frameworks, 2% on innovation and research, 5% on IT strategy planning, and 28% on roadmaps and assessments. Rick recognizes that the emphasis on current projects is an issue. Their challenge is to move from project focus to a strategy focus, generate measurable business value, manage the federated architecture discipline, and change the perception of EA (it had been seen as a roadblock/police force).

Their approach was to build credibility through their IT metadata. They have collected data from a number of different sources throughout the enterprise, integrating it into their EA repository. They had to standardize application names, and worked with internal audit to make it happen. Out of this, they built a number of business models, including ones that mapped the IT metadata to key business capabilities. Business capabilities have short, terse descriptions and they map these to the application that provide them.

Another area for improvement was to streamline their ARB (architecture review board) process. They have a standing weekly meeting where they can tie a product name to an ARB approval number, and they worked with finance to make sure nothing was funded that did not have an ARB approval number. This echoes a previous speaker who encouraged us to follow the money. Make finance/procurement a friend of EA.

They also created an EA value log, capturing value created, costs avoided, and other traditional measures.

Lessons learned:

• Set an EA strategy with metric based goals
• Develop credibility through collecting facts
• Know what works in your culture
• Find sympathetic partners (e.g. Audit, Risk, Compliance)
• Invest incrementally
• Promote successes

This presentation was given by Angela Yochem, a Business Information Executive with Dell.

Some trends:

• Reduction in size of IT.
• Move from centralized, global IT to a more decentralized model.

Successful response to these trends require a strong, empowered EA team.

Many companies are going through business transformations, yet we are still in a state where EA and IT are not involved early in the conversations. She queried the audience, and only and handful of people said they were involved from the beginning.

More trends mentioned by Angela include creative bundling and/or packaging of solutions for best value offering to customers, along with new offerings, new pricing models, and new channels. In the discussion around this, she suggested an intellectual exercise for use on April 1. Come up with a business transformation scenario that is just barely within the realm of possibility (or not, she suggested “what if a bank acquired an airline?”) and see how your EA team would respond. Do you have the information you need to respond properly to business change?

Next trend: Increased reliance on technology to enable business transformation. What would it take if your company needed to shift from selling its products to renting your products?

“We must be able to shift with changing/emerging business models.” These intellectual exercises are important for maintaining readiness, because this change is occurring all around us. “Now is the time to prepare – but most IT shops are not in a position to start.” Angela brought up the oft-quoted numbers of how much of IT spend is focused on keeping the lights on instead of new investments.

“Simplifying/globalizing processes are key to reducing IT complexity and increasing agility.”

“Cultural shifts – break reliance on f2f interaction, SMEs, additional funding, and the notion of ownership.”

Invest in business accelerating capabilities. Techniques to do this include developing expertise in business architecture capabilities; investing in acceleration teams, also known as innovation teams or SWAT teams (5-10 people that are funded out of baseline/overhead and find ways to accelerate time to market); and having strong toolsets. Knowledge is power.

Lastly, actively manage your own capabilities and career as you do your IT shop. She gave the analogy of the flight attendant instructions to put on your own oxygen mask before helping those around you. Make sure you are taking care of your own personal capabilities and the opportunities for you on an individual basis.

In discussing how enterprise architecture supports merger, acquisition, partnership, and other evaluation opportunities with some attendees at the Troux 2011 conference this morning, I used two terms: fit and fitness.

Fit is how well things align between the two companies/products. for example, what do the capability maps look like? Did things get sliced up in a similar manner, or are they completely different? How does each company map their technology into the capability map? if the capability map is similar and the mapping of technology to capabilities is similar, then this is probably a good fit.

Fitness is the state of the things being integrated or merged. You can have a great fit, but if it is built on outdated technology, or has a poor architecture, the fitness is poor, and thus there is more risk in pursuing the activity.

What do you think?

Moderator: George Paras, A&G Editor-in-chief
Panelists: Mike J. Walker, Principal Architect with Microsoft
Aleks Buterman, Founder, SenseAgility
Tim Westbrock, Managing Director EAdirections
Paul Preiss, CEO, IASA

This was a certainly a lively panel, and I don’t envy George’s task of trying to keep it on track. Here’s what I captured.

Q: What does top performing mean to you?
Mike: High performance for EA is really about having a business conversation to maximize and amplify business results.
Aleks: The ability to quantify value in such a way that stakeholders believe.
Tim: Top performing groups figure out the things they need to do in their organization, whatever it may be, but the common thing is to become more proactive and less reactive.
Paul: There is no such thing as a top performing enterprise architecture team, there is only top performing architecture teams. We can’t leave out the other 90% of architects in the profession. For them, it is the ability of them to claim revenue or shareholder value, owning technology value to the company.
Aleks: Herding architects, especially enterprise architects, is a very difficult thing to do.
Mike: We’ve done a poor job in really defining what architecture is. For Enterprise Architects, is that the right brand? I don’t think it is.
Paul: We care about all of the architects. Enterprise architects account for about 10% of the architects out there. There’s a reason that the term “ivory tower” is associated with Enterprise Architect, because the terms don’t address what 90% of the people do.
Mike: Fundamental issue: we’ve mixed enterprise architecture with IT architecture. Enterprise architecture is business driven and a peer to the CIO whereas technology architecture exists solely within IT.
Aleks: Sustainable innovation is driven by integration across several domains, and that’s what enterprise architecture is about.
Tim: The primary audience is left out in too many organizations. If you’re doing Enterprise Architecture, your audience should be the leaders of the enterprise. Instead, we find our time spent with the domain or solution architect with a mythical translation of the business strategy without ever having validated it with that business leadership. Organizations that do EA the best are actively engaged with the business leadership.

Q: Where should the EA organization report? Does it matter where they report? Should it be centralized or federated?
Paul: Did a survey, and about 95% of the room report in through CIO, only about 7 people in the room report outside of the IT organization. This is a non-entity question. Professions get one recognized value proposition.
Tim: I don’t believe that who you report to and who your audience is are the same thing. Most people report in through IT because that’s where it started. We’re one of the few organizations that deal with things enterprise wide. We’ve been saying that we should be aligned with the business for 15 years. We all gravitate toward the comfortable. Most of us came from the project role or domain role. When it gets hard where we can make a difference by going outside of that mold, the tendency is to retreat to what is comfortable. We need to get out of our comfort zone and go talk to business activities and figure out what we can do to help them, rather than what we can do to help projects work better.
Mike: On certifications: no one is getting sued over a bad software development project (Paul disagreed, says IASA is working on some such lawsuits). All up, there is a lack of accountability within IT, we have not done a good job of being credible with the business. If 80% of all IT projects fail, have we earned the trust of our audience? We haven’t earned a seat at the table, and we need to do so through incremental benefits.
Paul: We simply haven’t claimed a seat at the table. For example, we built a website for online retail and made a company $100 million. Marketing claimed success, and got their budget increased. We need to claim the value we deliver.

Q: How do we quantify top EA performance?
Aleks: when we are dealing with large scale environments, you can’t claim a seat, you have to be invited. If you don’t toot your own horn, no one else will. The way to do so is through metrics that make sense to the business leaders. You may not have a P&L, so you need to have partners that bring you into the discussion. You quantify the value to stake claim to your seat at the table and get invited in.
Tim: I don’t think you can quantify the value of enterprise architecture. We need to get much better at quantifying the impact the EA makes on the decisions that are made and the investments that are made. EA, by itself, has no real quantifiable value. We need to quantify the value of our impact.
Aleks: Should we be called investment managers instead of enterprise architects?
Mike: We haven’t talked about the soft skills required to be an enterprise architect.
Paul: IASA states the fundamental value of architects is the ownership of technology and its value. Technology investment is a fundamental driver for profitability in today’s marketplace, yet we continually treat it as a cost center. 60% of capital expenditures is technology, yet it is the only set that doesn’t have a robust set of NPV, etc. at the shareholder level.

Q: What pointed advice would you give the audience to get to where they need to be?
Q: Back to where EA should report…
Aleks: EA should report to the board of directors
Tim: Separation of responsibilities where business and information architecture report into the business, and application, technology/infrastructure, and data architecture report in through CIO.
Mike: Agree, but we need to look at the maturity of the organization throughout. Each industry has different principle drivers that influence the organizational structure and how you implement your architecture team. If you are a mid-sized bank, do you invest in a federated EA approach? Perhaps not, we have to be pragmatic and morph to the organization. We need a set of patterns that can be applied where they work.
Aleks: We have a guide called Enterprise Architecture as Strategy (Jeanne Ross book). If you have a diversified operational model, there are severe constraints on how much value you can add. Depending on what your operational model is, it will influence on how you structure EA.
Paul: Reporting doesn’t have any impact on the profession. We’re going to find it really hard to change the perceived value for our profession which is technology strategy. There are very few architects invited to talk about the sales process, except to make a model and understand the technology impact.

Back to how we can get there…
Tim: A lot of modeling that goes on is very bounded and implementation oriented. There are models that can’t get done within project/budgeted work. It’s part of the overhead for enterprise architecture. Do you have these models? If the answer is no, or some, then go create them. It’s a communication device that allows us to have the conversation. It the places where it happens, the communication tools need to be established so the EA can talk with the CEO. The CEO isn’t going to go to the CIO and ask to see the Enterprise Architecture guy.
Mike: All people are different and have different motivations. Our key to success depends on our ability to effectively communicate our value prop and what’s best for the organization to all of those stakeholders.
Aleks: You need to know the constraints you’re operating under according to the operating model, and you need to understand if you have an evidence-based management culture. If you don’t have an evidence based culture, it will be more challenging.
Tim: My experience has been that the models we create are nowhere near evidentiary. They tell a story and get people who have focused on making a silo as efficient as it can see how their decisions have impact the entire organization. It’s a hard conversation to have without visuals.
Paul: People have come up to me and said I get asked about SDLC problems, and we aren’t even doing architecture. Architects need to have skills in human dynamics, this is where we see architecture teams weakest. Second is business technology strategy, talking about business value and how do we make more money. Architects get tripped up on focusing on project success which is measured wrong. It’s not about done on time and on budget, it’s about the value it delivers.

Final comments:
Aleks: Think about the environment you’re in, just because something worked it one situation doesn’t mean that it will work in another. Find out what the stakeholders need to hear, and deliver that, rather than espousing the gut of EA.
Mike: Change our mindset, shifting from IQ to EQ focus. Think about the method of delivery, be action oriented and pragmatic. Finally, we have to always be about value.
Paul: Connect the architect team. Get them all on the same team understanding that we’re doing the same thing. Connect them on a skill level.
Tim: Spend time reading non-technical literature that is relevant to your business.

This was a panel discussion with representatives from Forrester (I believe), Troux, HP, and CA. The text below is my attempt to capture the points made by the speakers, and do not necessarily constitute my own opinions on these subjects.

I didn’t capture the first couple of questions, but here’s a couple important points that I heard.

Don’t call things compliance reviews, call it a business capability review. As part of that response, the speaker also said that we want enterprise architecture to be driving change, identifying the things that need to be done, and then get feedback from the PPM and systems management tools to make sure that the intended business benefits are being delivered.

On IT planning… it is frequently a shot in the dark in a reactive mode to the business strategy because the planners lack the information necessary to have a well-aligned plan.

From this point on, I tried to capture the question and the panelist responses.

Q: How does EA joined with the ITIL/ITSM space deliver better business value?
CMDB provides much more granular information about assets, such as incidents, changes, etc. The combination of this operational data plus the data contained in an EA repository like Troux has the potential to create even greater value and decision support. At the same time, throwing a bunch of ingredients together doesn’t get you a cake. You need to have a good cook.

Q: How do you see the CMDB and the cloud working together?
Discovery, topology visualization, impact analysis are all still important things. Wherever the owner of that infrastructure is, there must be ITSM, and a CMDB. Trend in CMDB is toward real-time information.

Q: The goal is to establish PPM, ITSM, CMDB, and operationalized EA. What would my 18 month roadmap look like, or where do I start?
Forrester: Personal opinion is to start with the PPM process. How do we evaluate an investment, what kind of stages does it go through, what information do we capture about the investment? Then, now that the project is complete and we have an application, how are we tracking its business value, its alignment. Then, with a CMDB, what’s going on beneath the covers in the operation of that application.

Q: This question was on the relationship between business services in ITIL and the business capabilities in Troux.
The response was that this was a very symbiotic relationship, allowing business context to be brought into the operational side. Troux allows us to establish relationships all the way back up to a business capability, which may be very important to a change management coordinator.

Q: Understanding that CIOs are striving to integrate IT in the business, how successful can a CIO be with limited to no control over the IT budget?
The first panelist lamented at the whole notion of “integrating” IT into the business. IT is part of the business, period. The lack of governance mechanisms that allow us to make a correlation between all assets in the organization and the business constituents it supports has put IT in this position. Another panelist pointed out that companies that are stuck in the “utility provider” archetype really struggle to ever get out of that role and into a trusted provider or partner/player type of relationship.

Q: Oracle takes a very fast approach to EA, incumbents take a more managed approach. Is one better than the other?
So many EA teams try and fail. We have our own framework for fast-tracking EA, but it is quick and dirty. Taking your time, in general, sounds better.
Bill Cason of Troux added that if you don’t build sustainable processes, you haven’t added any value. A big part of EA’s job is to get something sustainable, regardless of how fast you build it. Management doesn’t have a lot of patience for EA today.

Q: How can software deployment integrate with EA, PPM, ITSM, and CMDB? Can it be really integrated?
The most interesting answer from the panelists was the one who said, “How can we do this without integrating them?” and went on to talk about the relationships between PPM and SDLC. Full blown PPM also goes back three years after the release and verifies that we actually received the business benefits we said we would back when the project was approved.

Tannia Dobbins, IT Relationship Manager from Advanced Micro Devices, gave this presentation.

She walked through some of the key drivers behind enterprise architecture over the past 5 years at AMD, initially focused on supporting acquisitions and divestitures, moving into reducing complexity and risk when the economy downturn occurred, then to process efficiencies and business enablement, and now into core architecture and design.

A constant theme throughout her presentation was that they had strong backing from their senior leadership / stakeholders. An interesting fact, though, was there were four different CIO changes during this timeframe, yet they consistently maintaining the backing that they needed. When a new CIO came in, they had the inventory of assets ready to go with the ability to slice and dice it in various ways to meet the needs of their stakeholders.

One of the things that I really liked about Tannia’s presentation was their use of targeted landing pages into the Troux portal, and even more so, their use of scorecards in their monthly operations review. Two particular scorecards she showed were a technology scorecard and an application portfolio scorecard. Both of these contained information for all of the different ownership areas on one chart, red/yellow/green presentation (e.g. % of things compliant with standards, % of completeness of information, % of assets on “risky” technology, etc.). By putting all of the areas/VPs on the chart, it also encourages compliance through a bit of peer pressure. Everyone can see who is doing well and who isn’t.

Summary points:

• It is a journey, not a destination. Take time to understand the changing dynamics and needs of the organization.
• It takes more than just management commitment, but this helps!
• The power of a few, good evangelists can ignite a grass roots effort.
• It is all about solving business problems (and financial ones too).
• Changes in leadership can be a catalyst for a new level of maturity.
• Changes in IT maturity are opportunities to leverage Troux capabilities.

In this session, David Hood, CEO of Troux, talked about Troux’s approach to the market. He began by presenting “Zucca’s Equations”:
W²A: Where we are
W³TG: Where we want to go
HW(GT)²: How are we going to get there

He called out that the need for EA is increasing at a rate much higher than the maturity of the EA discipline, creating a gap. To fill that gap, he saw 4 keys to success:

1. Start with the end in mind
2. Make it repeatable
3. Make it easy to consume
4. Some parenting is required

In the section on censurability, David talked about visualizations, citing both the Facebook connections visualization (as an example of a beautiful visualization) and the Billion dollar-o-gram (as an example of a disruptive visualization). Visualizations of the information are important to the practice of Enterprise Architecture.

He ended with a slide containing a picture of Mary Poppins, indicating that sometimes a spoonful of sugar will be necessary to make the medicine go down. I think this goes hand-in-hand with making things consumable. Create a consumable version (sugar) of the information to get the bring light to the important information necessary (medicine) for our decisions that may have been an unknown item before.

Imran Qayyum, an EA for Cisco, was the presenter for this session. They used the Proact BOST framework (Business Operations Systems and Technology) to get started, providing an industry specific reference model.

Imran’s team is responsible for development services, which covers all sorts of software development technologies necessary for the Cisco Engineering teams to design and build cool stuff. They gave a good demonstration of how they are using Troux, walking through how they’ve defined their domain in terms of capabilities and business functions delivered to their customers, including roadmaps for the technologies and applications that support each business function.

In his wrap-up, he mentioned that they will be looking into integration with PPM and CMDB technologies. I believe that as EA tools increasingly move toward decision support, integration among these different systems will become increasingly important, especially ones that provide financial information, since that’s a huge component of decision making for business leaders.

Sandra McCoy, Executive Director for Enterprise Architecture with Kaiser Permanente, gave this talk, subtitled as “Architecting Standardization in a Complex Healthcare Organization.”

She mentioned that the challenges her team faces are that architects would like to work in a nice orderly fashion, but the environment never allows for that. It’s an uphill battle, with blind curves, treacherous consequences, insufficient resources, etc.

They chose to start with standards, focused on defining where they wanted to go, and less so on defining where they currently are. Standards must be clearly visible and easy to find. Their concepts must be easily understood, and they must be an enabler. They need to be marketed as an enabler and a safeguard.

One interesting anecdote in the discussion was that they initially created a big excel spreadsheet with their standards and got challenged by stakeholders to do something more innovative/cutting edge. It’s a great example that we’re always marketing ourselves in everything we do.

She reinforced the earlier points from Bill Cason and Warren Ritchie that we have to be able to describe our assets and resource to demonstrably show dependencies and impacts to business leaders as part of the decision making process.

In the Q&A portion, one person had caught that she had a box labeled “Innovation Standards.” This is the category for technologies that are under investigation that they wanted to track, including the results, to avoid having a bunch of people looking at the same thing in two or more different areas, or to also make the results of prior investigations available to others.

Her lessons learned were:

• Go slow to go fast: plan your approach (before you start talking to people), architect the 5 year vision, and create templates, messaging, RACIs and roaadmaps.
• Don’t market what you can’t support: Their repository has sold itself, people want the results but not the work (organization needed to participate to provide data for the repository), and create a collaborative approach.
• Don’t forget to practice what you preach: Architect first, ensure the EA tools and stack are standards, and architect a comprehensive enterprise architecture solution.