Patterns and Anti-patterns in Enterprise Architecture (PDF)

Patterns and anti-patterns and Enterprise Architecture Examples and Dell Case Study Enterprise Architecture Pattern (EAP) Enterprise architecture Design practice. A Pattern is a general reusable design solution to a commonly occurring problem within a given...

Patterns and anti-patterns and Enterprise Architecture Examples and Dell Case Study Enterprise Architecture Pattern (EAP) Enterprise architecture Design practice. A Pattern is a general reusable design solution to a commonly occurring problem within a given architectural context. helps you finding solutions without repeating the errors of others. Enterprise Architecture Pattern (EAP) helps finding a common understanding of the problem and its solution. EAP has always the same shape, it begins with choosing a meaningful name and has the description of the problem to be solved. Layered pattern. Such as example in Programing Client-server pattern.  The Pattern Catalog The pattern catalog divided into three categories. The patterns in the categories use or provide interface to the other patterns in the same category or in another category. The O-shaped connectors represent the provided interfaces and the U-shaped connectors the use of an interface. The Pattern Catalog Business Patterns are directly related to a core business process. The use of these kinds of patterns is dependent on the sector in which the company or organization makes business (like patterns for health care, finance or the automotive industry). Support Patterns are related to the typical support processes of a company like human resources, financial services and logistics. We put all patterns in this category that are not directly involved in a core business process. Infrastructure Patterns provide basic services for all patterns. The services are often not directly visible to end users but are essentials for the effective and efficient functioning. Enterprise Architecture Pattern (EAP) Example Enterprise Architecture Example Single Sign on (SSO) SSO is a type of access control of several software systems. Single versions of SSO can be gotten via IP networking. Users can access the whole system by an individual ID.  Enterprise Architecture Example Web and EJB Operations The example shows the general operation process of Web and EJB elements. Web elements are based on database resources, and Notice Management is close to multiple database sets. Anti-pattern Anti-pattern is an ill-advised solution attempt to solving a common problem. It is like people stuck in traffic jams start changing lanes. They have the best intentions of getting ahead. It doesn’t solve the problem, on the contrary, it can actually make it worse. Example 1 (Donkey in a Tiger Skin) Starting an Enterprise Architecture practice while the organization is actually doing something else. Example 2 (Zealotry) Being too focused on the purity of “Enterprise Architecture” instead of its effectiveness. Example 3 (Process without people) Defining Enterprise Architecture processes without identifying people responsible for executing them or consequences for them for not implementing them. Example 4 (Non-Political) Creating a program without consideration to the organizational politics.  An Oracle Enterprise Architecture Case Study IT Transformation at Dell Dell Long known as one of the world’s largest manufacturers of personal computers, Dell has grown into not only a multi-national hardware and infrastructure provider but also an IT services and solutions provider as well. Rhonda Gass, Dell’s Vice President of IT Strategy, Technology & Governance, is charged with mapping out a future direction for the IT giant, with a three- year roadmap driven by Dell’s Enterprise Architecture (EA) team. This roadmap includes ten major programs, each of which involves investments in the tens of millions of dollars—and, in some cases, hundreds of millions of dollars. These programs include: Global Quote to Cash, Global Service Delivery, Solution Selling, Global Manufacturing Execution, and Recurring and Usage based transactions. Oracle is providing executive guidance for this transformative journey, working closely with Gass and her enterprise architects to establish a long- term view of the requisite processes, systems and technologies.  The Problem: Creeping Diversity Several years ago Dell began a transformation from a hardware infrastructure provider to a software solutions and services company. Dell acquired several large companies in 2010, including Perot Systems, and three other companies in 2011. “To grow effectively we knew we needed a solid technology base,” “‫لك ننمو بشكل فعال كلنا نعلم أننا بحاجة إىل قاعدة تقنية صلبة‬ ‫” ي‬ Gass recalls. “Simply layering new capabilities on our existing systems wasn’t going to work anymore.” «‫ لن يعمل والوضع اإلمكانيات جديدة عىل أنظمتنا الحالية بعد اآلن‬، ‫»ببساطة‬ The Problem: Creeping Diversity For example, when Dell wanted to implement a common electronic payment type for all of its online and offline sales properties around the world, the IT department estimated that it would take 18 to 24 months to develop this service and deploy it globally. IT leaders realized that having 12 different order management systems, 27 different interfaces for product and customer data, and disparate data representations in the data warehouse, was inhibiting Dell’s ability to transform. “This was a call to action for management, not only within IT, but among the business leaders,” continues Gass. “It was a joint problem that necessitated a top-down approach. We needed to embrace globalization, consolidation, and standardization to make headway. Disparities in our information systems were inhibiting our ability to transform.” A Process for Rationalization (Planning) In order to achieve its corporate objectives, Dell needed to rationalize its IT infrastructure. This transformative process involved consolidating multi-national systems to improve efficiency, reduce costs and enforce common standards. Rationalizing involves understanding the current state of an organization’s IT and business processes, and then mapping business capabilities to IT capabilities. In Dell’s case, the EA team began by establishing an enterprise vision—a blueprint to guide individual projects. This blueprint laid out the structure of the enterprise in terms of its strategy, goals, objectives, operating model, capabilities, business processes, and information assets. Using the blueprint, enterprise architects can now understand all applications and the underlying technology currently in use and then map the applications to business capabilities to identify omissions and redundancies and overlapping and duplicate applications. Driven by Architecture Dell’s Enterprise Architecture team includes business architects, information architects, application architects, and infrastructure specialists. They have completed the rationalization process and are beginning the next stag: business process transformation. These changes are as much cultural as they are technical. After creating a center of excellence (COE) to study its fundamental business processes, Dell organized the company around five key “process areas,” each of which exists to enhance the customer value chain: Develop - Market- Sell- Fulfil- Support Process owners in each area are partnered with IT to establish the future systems that will run these areas based on process and capability needs. Driven by Architecture “Dell used to think about the physical processes that run the company,” Gass explains. “Business architecture considers logical processes and cross-domain capabilities. That’s what we are designing now. It’s a huge change.” For example, one area that Dell identified development and delivery of support tools. Various product teams (e.g., notebook team, desktop team, server team, etc.) were capturing diagnostic information for evaluation. Gass believes that IT must lead the business in any type of large, transformative project. A Foundation for Execution Establishing business architecture involves capturing various “views” of the enterprise such as the business strategy, business capabilities, business processes, knowledge, and organization. In most EA projects, this information is used throughout the architecture development process to: ❑ Identify business and IT “owners” to sponsor and participate in the architecture review and transformation process ❑ Prioritize the areas in which to focus rationalization efforts ❑ Capture business capabilities and business process insight ❑ Eliminate redundancies and gaps in the applications portfolio ❑ Align IT initiatives with business strategies and goals Dell has a systematic method for achieving these objectives. Every year its business architecture team sits down with the strategy planning office to review essential capabilities and complete a strategic plan. This plan typically focuses three to five years in the future. Gass and her team maintain a corporate-wide map of these capabilities that depicts specific business domains – what they call “process chevrons.” This map provides a logical model of how Dell runs. The business architecture team looks for “capability gaps” and then interacts with the solution architecture team, the information architecture team, and the infrastructure team to fill those gaps. Creating Business/IT Alignment Dell prioritizes its IT investments by aligning them with the reference architecture and identifying the capabilities with the highest return on investment. Gass and her team enforce the technology reference models and provide an architecture review board to govern the transformation effort. The EA team periodically assesses the degree to which each project has realized the transition state on the way to the three-year reference architecture. Creating Business/IT Alignment Enterprise architects are required to understand those processes in relation to the organization’s overall business strategy. This knowledge helps to ensure that each department conforms to consistent business practices, processes and standards. EAs maintain a cross-domain perspective that represents the vision and requirements of the organization as a whole. Enterprise architects are typically not process analysts. They define how a process interacts with other core processes, and how a process impacts the organization. To do this well they must understand the external and internal factors that influence the organization. External factors include things like compliance, which are imposed from without. Internal factors include specific IT standards and operational business requirements.