Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Enterprise architecture standards

492 Aufrufe

Veröffentlicht am

  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Enterprise architecture standards

  1. 1. Enterprise architecture standards The good and the evil Skill Level: Introductory Kunal Mittal (kunal@kunalmittal.com) Executive Director, IT Sony Pictures Entertainment 18 Mar 2008 In this article, learn about some fundamental challenges that IT teams face when working with enterprise architects, and find out how to apply enterprise architecture standards to application development and cooperate in project delivery to reach a desired outcome. The role of enterprise architecture (EA) is changing. Adoption of Service-Oriented Architecture (SOA), Web 2.0, and other technologies is changing the way software systems are built. You can argue that traditional EA concepts are at the opposite end of the spectrum compared to Web 2.0 and SOA-based software development. In fact, I've heard arguments that the need for strong EA will diminish as organizations mature in their SOA adoption. This article, however, is really not about how Web 2.0 and SOA development affects EA. Instead, it's about some fundamental challenges I've discovered in how line-of-business IT teams work with EA teams in large organizations. It points out common issues with how EA organizations are structured and managed and presents a recommendation for how you can organize EA. I touch on Web 2.0 and SOA to emphasize how all the issues are compounded. Authority without responsibility Despite the benefits of a having a strong EA team, there is often tension between the enterprise architects and the project teams responsible for delivering applications and solutions to the business. What is the cause of this tension? Enterprise architecture standards © Copyright IBM Corporation 1994, 2007. All rights reserved. Page 1 of 6
  2. 2. developerWorks® ibm.com/developerWorks In many organizations, EA teams see themselves as having decision-making or approval authority over project teams. The EA team might require the project team to seek approval for several different aspects of its project, including technology platforms and versions, interfaces and communication, and software development processes. The EA team may also require project health checkpoints. Let's look at a hypothetical scenario. Example: Using Web services to integrate two applications I have seen EA teams insist that all communication between two stand-alone Java™ 2 Platform, Enterprise Edition (J2EE) applications happen using Web services. On the surface, that seems like a reasonable requirement. However, the project team could determine that Web services integration won't allow one of the applications to meet its performance service level agreements (SLAs). The project team decides to join data from one of the applications with data in its system. Then, as users perform searches on a Web page, the team uses Asynchronous JavaScript™ + XML (Ajax) to display the search results that consist of the joined data (that is, data from both systems). In this simple scenario, are Web services the appropriate integration mechanism? Maybe, maybe not. The enterprise architect has not considered the SLAs and tries to enforce the Web services integration. The project team has no choice but to go with Web services, and during quality assurance or user testing, the performance SLAs are not met. The project team ends up working 12-hour days to try to meet the SLAs and deploy the application on time. In this case, where is the enterprise architect who made the decision or enforced the requirement to go with Web services? Typically, he or she is nowhere to be found. This is a classic example of authority without responsibility. This might all seem silly. However, if you're a project team member who has worked within a larger organization with a maturing EA, you can probably relate to it. You may be asking yourself, why is my enterprise architect not sitting here with me solving this problem? Solution: Roll up your sleeves The solution to this is easy (although perhaps easier said than done). Enterprise architects must have two functions: the governance function and the project-delivery function. Enterprise architects must be held as accountable for the delivery of the project as the application architect and the rest of the application team. Their role is not merely to define and enforce the use of standards, but—more importantly—to help the project teams work with those standards. Enterprise architects should never be too busy to help the project team in such a scenario. It's not enough to create, model, and document the standard. I would rather see Enterprise architecture standards Page 2 of 6 © Copyright IBM Corporation 1994, 2007. All rights reserved.
  3. 3. ibm.com/developerWorks developerWorks® enterprise architects define fewer standards but make sure that they spend adequate time supporting them as part of the project team's delivery. They need to be collocated with the project team or travel to meet the project teams. They should be available and accessible to fully understand all aspects of the project under development—from business, technical, and political perspectives. Authority and power come from influence. Enterprise architects must build strong relations with the project team, and the project team needs to value them as true partners and see that they are working alongside the project team in case of problems. This approach will automatically lead to influence and thus the governance that is a key function of enterprise architects. Following is another hypothetical scenario. Example: Defining your applications as services This example is a scenario in which the EA team has started to talk about SOA. A big new project comes around, and the enterprise architect sees it as an opportunity to demonstrate SOA. The enterprise architect would like this application to be built as services to expose services to the rest of the organization. On the surface, this is again a reasonable expectation. However, more often than not, the enterprise architects offer a one-size-fits-all approach. They have not spent the time to understand the requirements and business drivers of the project and are not involved in the details. The project delivery team is furious, because they're sitting in meetings, being questioned on how and why they need to expose and consume services. From their perspective, the enterprise architect is speaking theoretically, not comprehending the pressures and priorities of delivering the project. If you're an enterprise architect or someone who runs an EA organization reading this, you're probably thinking this is ridiculous. Are these examples a little too extreme? Even as a project delivery team member, you might think they are. I beg to differ. I have seen these scenarios very often and have heard enough project teams complain about their EA organizations in similar ways to be confident saying that these are very real issues. Many Fortune 500 companies face these issues to varying extents. So, how do we fix this scenario? Solution: Understand the business It's critical for each member of the EA team to understand the business. It's equally important to realize that the EA standards and practices must evolve as the business evolves. The evolution of the business must include changes in the IT strategy, which in turn should help determine the architectural strategy. The key words here are process, support, and alignment. Enterprise architects bring Enterprise architecture standards © Copyright IBM Corporation 1994, 2007. All rights reserved. Page 3 of 6
  4. 4. developerWorks® ibm.com/developerWorks process to the delivery teams. They need to lend support to these teams as well, and align their strategy and goals with the business drivers behind each project. Now, let's switch gears and see what typical IT organizations actually do as opposed to what they should be doing. EA is not aligned with the business A majority of EA teams that I have interviewed seem to focus more on the technology than on the business. They might start off building a strategic IT plan or interviewing the lines of business, but they end up with technology initiatives rather than business initiatives. Many EA teams spend more time defining the data center strategy or working on e-mail or directory initiatives, procurement, and so on. Don't get me wrong: These are critical IT initiatives that need the appropriate attention. However, from an EA perspective, they are all tactical projects, not strategic. In other cases, I've seen EA teams work on defining technology road maps, standards, and SOA strategies. This is another set of activities critical to an IT organization, but would working on them let you gain the true value of the EA organization? These initiatives have IT impacts but no direct business impacts. Who should perform these tasks, and what should the EA team be doing? This is a difficult question with no correct answer. I don't want to say that enterprise architects should not work on the activities and projects described earlier. They absolutely need to. However, this should not be all that they do. If such tasks are all they have the staff, time, and budget to work on, then maybe they should not brand themselves as enterprise architects. Or, they should work on these tasks, but then avoid the problems described earlier in this article. The EA team must be business-focused. The team members must build strong relationships with both the business leaders and the IT teams. They need to be thought of as partners, not police. The positioning of EA should be defined as a set of tools and services that help business decision making. At the end of the day, the EA team should be a bridge between the business strategies and the IT implementations. How does SOA fit in? SOA is about how IT can adapt to the changing business climate. The key driver behind SOA is business agility. If you agree with that, you will agree that to support the business, the EA has to continually evolve with the business. Enterprise architects are continuous modelers of IT strategies to support evolution in the Enterprise architecture standards Page 4 of 6 © Copyright IBM Corporation 1994, 2007. All rights reserved.
  5. 5. ibm.com/developerWorks developerWorks® business architectures. In an SOA—particularly in a Web 2.0 SOA—world, you're bound to see more resistance to rigid EA processes, guidelines, frameworks, and methodologies. The best way to overcome this resistance is for enterprise architects to partner with delivery teams and define their processes and frameworks in an agile manner—by which I mean that the framework, process, methodology, and governance policies must all be inherently able to change and adapt to SOA, Web 2.0, and beyond. Enterprise architecture standards © Copyright IBM Corporation 1994, 2007. All rights reserved. Page 5 of 6
  6. 6. developerWorks® ibm.com/developerWorks Resources Learn • Learn how companies are adopting the newest Web 2.0 technologies.. Get products and technologies • Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®. Discuss • In this Inside Architecture Blog, read how EA enables Web 2.0. • Learn about EA and Web 2.0. • Check out developerWorks blogs and get involved in the developerWorks community. About the author Kunal Mittal Kunal Mittal is a consultant specializing in Java technology, J2EE, and Web services technologies. He is the coauthor of and has contributed to several books on these topics. He works as a director within the Domestic TV IT group for Sony Pictures Entertainment, where he's responsible for the technical architecture and management of applications for that division. In his spare time he writes for IBM developerWorks, consults on SOA, and is a private pilot. For more information, visit Kunal's Web site at www.kunalmittal.com or contact him at kunal@kunalmittal.com. Trademarks IBM is a trademark of International Business Machines Corporation in the United States, other countries, or both. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Enterprise architecture standards Page 6 of 6 © Copyright IBM Corporation 1994, 2007. All rights reserved.

×