1. MTI - Perencanaan Infrastruktur BH-2002/v1.0/1 Adaptive Infrastructure: Identifying and Using Pattern Sjarif Abdat (sabdat@cs.ui.ac.id) Universitas Indonesia

2. MTI - Perencanaan Infrastruktur BH-2002/v1.0/2  Reference:  The Adaptive Enterprise: IT Infrastructure Strategies to Manage Change and Enable Growth Bruce Robertson and Valentin Sribar Addison Wesley, 2002

3. MTI - Perencanaan Infrastruktur BH-2002/v1.0/3 Pattern-based  Instead of developing infrastructure from the ground up for each new application, businesses can leverage a limited number of reusable infrastructure patterns.

4. MTI - Perencanaan Infrastruktur BH-2002/v1.0/4 Designing for the future  It is impractical and inefficient to allow infrastructure and business process to grow unchecked with separate decisions and implementations each time an applications is deployed  Recognizing patterns allows you to reuse existing technology, business process, and the skills of existing personnel  The pattern set must be variable enough to cover all major application requirements, but limited in number to deliver the benefits of a simplified environment.  Patterns must also provide sufficient detail to enable the design and implementation of high-quality, end-to-end solutions with minimal customization.

5. MTI - Perencanaan Infrastruktur BH-2002/v1.0/5 Relating Patterns to Platforms

6. MTI - Perencanaan Infrastruktur BH-2002/v1.0/6 Relating Patterns to Platforms  Pattern are the information, insight, and experience – the “what is” and “how to” – that are common to an existing class of application  This information is captured in a form that makes it easier to reuse with future applications of the same class.  Patterns also capture experience and best practices for projects that result from real apps requests by business  They emphasize end-to-end reuse in a logical rather than physical.  Patterns deal with applications, platforms deal with technologies  Platform requirements are IT-driven, pattern requirements are more directly driven by business needs  Patterns are designed to address application requirements by providing a proven and tested solution

7. MTI - Perencanaan Infrastruktur BH-2002/v1.0/7 Why So Few Patterns  80%-90% of all infrastructure needs can be consistently accommodated by a set of less than ten patterns  The specifics of these patterns may change to accommodate new technologies  It should be small  When you have too many options, complexity becomes a problem.  It’s difficult to maintain expertise in too many areas, designing a limited set of patterns will help you keep your focus.  Keep in mind the 80/20 rule and leave the last 20% of differences outside of the standards  Are patterns just for new infrastructure?

8. MTI - Perencanaan Infrastruktur BH-2002/v1.0/8 The Starter Kit  META Group recognize a set nine starter patterns in three basic interaction types:  Transact patterns Applications in which business data is written and stored for long period of time, such as online customer orders and other transactions  Publish patterns Applications with read-only data, such as online marketing information  Collaborate patterns Applications where information contained in files and documents is shared between two or more users, such as a product design document shared by a development team.

9. MTI - Perencanaan Infrastruktur BH-2002/v1.0/9 The Starter Kit

10. MTI - Perencanaan Infrastruktur BH-2002/v1.0/10 Pattern Maturity

11. MTI - Perencanaan Infrastruktur BH-2002/v1.0/11 Transact Patterns  Transact pattern include any application that “writes” structured information to a system or a data set  Transactions let you Create, Read, Update, and Delete (CRUD)  A DBMS is usually a standard component of this patterns  Require ACID properties (Atomic, Consistent, Isolated, and Durable)  Sub-classified using the following logical tiered structured:  1-Tier Transact, or Host Transact, where all data processing is done on the host system in a monolithic application  2-Tier Transact, which typically bring the presentation and business logic to the client side, leaving the database management on the server  3/N-Tier Transact, which, in addition to separating data management like 2-Tier, separates the presentation logic from the business logic

12. MTI - Perencanaan Infrastruktur BH-2002/v1.0/12 1-Tier Transact Pattern  This patterns includes batch applications or online transaction processing (OLTP) without logical abstraction between the presentation, application, and data logic.  Most mainframe implementations fall into the 1-Tier Transact Pattern  The entire application, including the database, business logic, and presentation logic, is hosted on a single, high- end server  Great for serving large user populations with massive transaction rates, fast response times and high availability

13. MTI - Perencanaan Infrastruktur BH-2002/v1.0/13 1-Tier Transact Pattern

14. MTI - Perencanaan Infrastruktur BH-2002/v1.0/14 1-Tier Transact Pattern  Benefits:  Availability. The host pattern’s availability is common strength familiar to infrastructure developer  Scalability. This patterns excels in the number of concurrent users it can support  Reliability. This pattern is also the most reliable. System recovery problems are often handled automatically

15. MTI - Perencanaan Infrastruktur BH-2002/v1.0/15 1-Tier Transact Pattern  Weaknesses:  Expensive. Users have to pay a premium price for mainframe hardware and software licenses.  Inflexible. Changing the system requires a significant engineering effort.  Lacking agility. The shared nature of applications can generate significant interrelated workload dependencies.  Lack of applications. Package application support is declining  Resource-intensive.

16. MTI - Perencanaan Infrastruktur BH-2002/v1.0/16 1-Tier Transact Pattern  Best Practices:  Put wrappers around legacy host code to encapsulate the components and make them reusable  Avoid using this pattern for new applications  Don’t use components optimized for this pattern in other patterns  Minimize the investment in upgrading this pattern  Futures:  No new applications should be based on this pattern.

17. MTI - Perencanaan Infrastruktur BH-2002/v1.0/17 2-Tier Transact Pattern  This pattern involves a smart PC on the desktop communicating directly with a back-end database server  It also includes web servers that intertwine CGI/ASP/JSP presentation and application logic  The heavy integration of application logic and screen presentation logic make app-to-app integration difficult  Best suited for implementation on a LAN, in an environment where bandwidth are high and latency are low  SQL statements and database access middleware typically perform poorly over higher latency and low bandwidth WAN  How can you tell if an application is 2-Tier or 3-Tier?

18. MTI - Perencanaan Infrastruktur BH-2002/v1.0/18 2-Tier Transact Pattern

19. MTI - Perencanaan Infrastruktur BH-2002/v1.0/19 2-Tier Transact Pattern  Benefits:  Speed. The best choice for applications being deployed in a high-risk, volatile business environment, where business cycle are measured in weeks rather than months or years  Rapid development. Delivery can take place at a rapid clip

20. MTI - Perencanaan Infrastruktur BH-2002/v1.0/20 2-Tier Transact Pattern  Weaknesses:  Lack of scalability  Security vulnerabilities  Sourcing limitation  Presentation limitation  Lack of API  Hidden Cost

21. MTI - Perencanaan Infrastruktur BH-2002/v1.0/21 2-Tier Transact Pattern  Best Practices:  Limit this pattern to small-scale applications in a LAN- based environment  Be wary of adapting this pattern to WAN-based clients using a terminal server  Don’t use the Web version of this pattern for large- scale applications  Take advantage of this pattern for rapid prototyping

22. MTI - Perencanaan Infrastruktur BH-2002/v1.0/22 2-Tier Transact Pattern  Futures:  Prototyping and piloting will continue to use this pattern  Smart PC version wanes  ISVs slowly migrate from this pattern to N-Tier Transact

23. MTI - Perencanaan Infrastruktur BH-2002/v1.0/23 3/N-Tier Transact Pattern  This pattern consist of a thin client carrying presentation-logic only, communicating with a client- neutral, server-based applications, and a back-end database server  The most scalable and flexible client/server transaction pattern  Users can be highly decentralized (WAN-friendly)  Flexible to integrate with other applications or points of interaction.  Offers the greatest distribution of processing functionality in a transactional environment  Clients in this pattern tend to be thin, and shared business logic can be supported from multiple point of interaction

24. MTI - Perencanaan Infrastruktur BH-2002/v1.0/24 3/N-Tier Transact Pattern

25. MTI - Perencanaan Infrastruktur BH-2002/v1.0/25 3/N-Tier Transact Pattern  Benefits:  Scalability. Distributing the processing load on multiple server tiers provides significant scalability oRequires more design effort to partition application functions and limit dependencies  Security. Web SSO products provide multi tier security with role-based resource authorization  Presentation. All user interfaces can leverage the same application logic, both logical and physical  API. Ability to use APIs independently of the application’s presentations is the key advantage oReduces the cost of EAI because of sharing APIs between applications reduces the time and expense required to integrate the apps

26. MTI - Perencanaan Infrastruktur BH-2002/v1.0/26 3/N-Tier Transact Pattern  Weaknesses:  Need customization. Requires significant customization at application and tool levels  Misunderstood. Web server based is not always 3/N-Tier  Expensive. System integrators maintain that integration and implementation expenses will exceed hardware and software by a 4-to-1 ratio.

27. MTI - Perencanaan Infrastruktur BH-2002/v1.0/27 3/N-Tier Transact Pattern  Best Practices:  Develop Transactional Integration services to match 3/N-Tier applications  Work closely with application developers in the early stages, as they build or buy tools  Use scale-out stateless farm architecture  Use experience gained from existing OLTP DBMS and server OS/hardware platforms, even if other server tier platforms are different  Do not replicate OLTP data to scale  Take advantage of 3/N-tier pattern benefits when scaling and integrating with other applications  Develop a Test Lab, including equipment and procedures for investigating the infrastructure impact of various patterns and services

28. MTI - Perencanaan Infrastruktur BH-2002/v1.0/28 3/N-Tier Transact Pattern  Futures:  Continue to be the preferred choice for transactional applications  ISVs slowly migrate to this pattern  Better app development tools supporting this pattern

29. MTI - Perencanaan Infrastruktur BH-2002/v1.0/29 Stateless Farm Architecture and Scale- Up Design  Scalability and availability can be approached using:  Scale-up  Scale-out  Stateless Farm Design:  Application designer understand how to build statelessness into Web applications  HTTP makes it possible -> IP redirection, to distribute the load to number of Web servers  For transactional apps, requirement still exists to maintain user session information.  Application state is achieved using cookies, decorated URLs, or persistence mechanisms provided by the load balancers.  Storing state in the database is the most safe and reliable design, even it it limits performance

30. MTI - Perencanaan Infrastruktur BH-2002/v1.0/30 Stateless Farm Architecture and Scale- Up Design  Clustering Database  General-purposes commercial database apps are more difficult to parallelize, given the need to maintain state centrally  Best practice is to use clusters primarily to enhance DBMS server availability, not to extend scalability  Scalability issues will be addressed by new software products, such as Oracle 9i Real Application Cluster (RAC), and new hardware technologies.

31. MTI - Perencanaan Infrastruktur BH-2002/v1.0/31 Stateless Farm Architecture and Scale- Up Design  Clustering Other Servers  To scale Web applications can be addressed by implementing DNS round-robin load balancing.  Simple DNS policies are not sophisticated enough to avoid unhealthy servers in cluster  Vendor have developed server load balancer (SLB) and network load balancer (NLB) products to improve reliability, performance, and manageability of server clusters  They distribute the processing load based on various policies, including round-robin, least connections, and CPU load  The three core advantages to NLB solutions are: oIncreased redundancy oBetter performance oEasier management

32. MTI - Perencanaan Infrastruktur BH-2002/v1.0/32 Publish Patterns  Publish patterns include most applications that provide read-only and data analysis access  Scaling these infrastructures is usually a matter of replicating the data as much as needed to support volume and reliability  Publish applications are the most easily and commonly outsourced (when the goal is to serve very large number of users over large geographies)  Sub-classified as:  Client/Server Publish, usually leveraging complex GUI analysis tools  Web Publish, where the data-access is initiated in a browser  Stream Publish, an emerging pattern that covers near real-time audio and video downloads

33. MTI - Perencanaan Infrastruktur BH-2002/v1.0/33 Client/Server Publish Patterns  This pattern is defined by the use of a smart PC, such as a sophisticated business intelligent client, with session- oriented protocols.  Best used for implementing sophisticated data analysis capabilities for small, well-defined user base.  Applications that fit this pattern are online analytical processing (OLAP) tools and reporting-intensive application  This client/server pattern is the most popular Publish pattern inside the enterprise

34. MTI - Perencanaan Infrastruktur BH-2002/v1.0/34 Client/Server Publish Patterns  Fig 3.8

35. MTI - Perencanaan Infrastruktur BH-2002/v1.0/35 Client/Server Publish Patterns  Benefits:  Highly adaptive. It reduces the number of interface and the number of extractions that have to be performed on the operational system  Weaknesses:  Resource-intensive. Client code size and bandwidth requirements make this pattern less easily scalable and deployable (tend to be restricted to LAN use)  Unpredictable demand. It is not uncommon for the answer to a query to be 100 to 200 megabytes or more in size

36. MTI - Perencanaan Infrastruktur BH-2002/v1.0/36 Client/Server Publish Pattern  Best Practices:  Developers must pay close attention to modeling in order to maintain system performance  Manage data access closely, both educated and uneducated users may be accessing these applications, and a tiny mistake in an SQL command can bring a data mart to its knees  Consider using a separate OLAP server to optimize performance by pre- calculating and storing results for common queries  Use this pattern only for data-intensive, read-only applications  Due to the bandwidth requirements, this type of pattern should typically be used in a LAN environment only  You should use one of the Transaction pattern to handle the write- back/change requirements resulting from analyses  Create a unified analytic service using a Data Warehouse/Operation Data Store (DW/ODS)  Use publish-specific tools such as OLAP analysis tools rather than VB or PowerBuilder

37. MTI - Perencanaan Infrastruktur BH-2002/v1.0/37 Client/Server Publish Patterns  Futures:  Client-based slicing and dicing of data will remain popular, especially for disconnected users  Convergence of Web and Client/Server publish with ability to move transparently between them

38. MTI - Perencanaan Infrastruktur BH-2002/v1.0/38 Web Publish Patterns  This pattern is defined by the use of an HTML browser and HTTP protocol to enable read-only access to structured XML or HTML documents  More flexible than Client/Server Publish pattern in supporting large, less well-defined user groups  Most popular for applications reaching beyond the enterprise boundaries  Many Web sites today use a combination of Publish and Transact patterns  However, infrastructure planner should separate these distinct functions to get a better picture of the infrastructure that is needed for each activity

39. MTI - Perencanaan Infrastruktur BH-2002/v1.0/39 Web Publish Patterns

40. MTI - Perencanaan Infrastruktur BH-2002/v1.0/40 Web Publish Patterns  Benefits:  Due to the maturity of this pattern, many solid tools are available for developing read-only Web publishing apps  Speed of initial development  Wide availability of Web hosting service provider  Scalability is very simple to achieve by scale out, rather than scale up (stateless farm architecture)  Performance-enhancement solution: oNetwork load balancer and multi-site balancing oCompression oCaching (reverse caching in DC, client caching, intermediate ISP caching) oContent delivery network (CDN) services like Akamai oTraffic or rate shapping

41. MTI - Perencanaan Infrastruktur BH-2002/v1.0/41 Web Publish Patterns  Weaknesses:  Difficult to manage scale or load on e-Business Web sites that fit this pattern  Difficult to change the presentation logic from Web to non-Web presentations without completely rebuilding the application  Publishing to multiple points of interaction is still a work in progress

42. MTI - Perencanaan Infrastruktur BH-2002/v1.0/42 Web Publish Pattern  Best Practices:  Focus on availability first, then on throughput and response time  Plan for at least two-way redundancy, even for internal systems  Examine Web-hosting service providers for designs and sourcing  Consider using Content Delivery Network (CDN) services for static content, but only for very large audiences  Scale out (duplicate and replicate) Web and data servers with load balancers  Support multiple point of interactions (or at least plan on this in the future  Manage, limit, or disallow direct access to transactional data  Avoid running transactional applications on infra-structure designed for the Web Publish pattern  Create a unified analytical integration service via DW/ODS

43. MTI - Perencanaan Infrastruktur BH-2002/v1.0/43 Web Publish Pattern  Best Practices (cont):  Don’t use expensive Online Transaction Processing database  Leverage less expensive hardware and software in general for data storage component.  Don’t neglect security issues. Be sure to guard against data defacement and denial of service attacks  Coordinate with marketing personnel and other business decision- makers, to estimate the impact of business cycles, marketing campaigns and other business variables on application workloads  Design for outsourcing. Even if you decide not to outsource now, this is an increasingly cost-effective option for many businesses, and may be advantageous in the future  Install response time and load monitoring services for business-critical applications  Take a service-centric approach. Once you have optimized this pattern, it can be widely reused with minimal or no customization.

44. MTI - Perencanaan Infrastruktur BH-2002/v1.0/44 Web Publish Patterns  Futures:  N-Tier publishing based on XML, XSLT, and XQL  Convergence of Web and Client/Server publish with the ability to move transparently between them

45. MTI - Perencanaan Infrastruktur BH-2002/v1.0/45 Stream Publish Patterns  This pattern is used for real-time publishing of streaming content to “multimedia player”  Streaming plays the file in near real-time as it download  The latency requirements of real-time multimedia delivery are critical  Stream publish is only one-way  Streaming multimedia requires great changes in user behavior, Web site loads, and network configuration

46. MTI - Perencanaan Infrastruktur BH-2002/v1.0/46 Stream Publish Patterns  Benefits  Usability. Streaming content is much easier to use simply because little interactivity is involved  Business value. Streaming content can make web sites more dramatic and interesting (increase customer retention)  Clear choice Vendor solution are coalescing slowly, which makes specifying solutions easier to do

47. MTI - Perencanaan Infrastruktur BH-2002/v1.0/47 Stream Publish Patterns  Weaknesses:  Bandwidth-intensive which also can mean expensive  Unpredictable result Unpredictable and variable network can affect the streaming quality  Unpredictable demand E-Business or consumer-focused sites normally have an unknown external user base.

48. MTI - Perencanaan Infrastruktur BH-2002/v1.0/48 Stream Publish Pattern  Best Practices:  Find a qualified service provider to host large-scale content streaming. Be sure they are equipped to handle dynamic bandwidth needs quickly and efficiently during peak demand  Don’t use gratuitous streaming content on web pages, since it complicate infrastructure requirements while perhaps providing little business value  Monitor usage carefully. Traffic spikes are common with streaming content, and poor quality of service can largely negate the business benefits  Use traffic shaping to control the impact of streaming content on other Web applications  Use multicasting whenever possible for internal viewing of popular streaming content  Internally, consider using scheduled replication of content to servers that are logically and physically closer to large user populations, instead of running streams over WAN.  Monitor corporate intranet sites for overuse of streaming media links

49. MTI - Perencanaan Infrastruktur BH-2002/v1.0/49 Stream Publish Patterns  Futures:  Increasingly advanced compression algorithms will improve the streaming quality  Streaming publishing will evolve into multicasting  CDN are adding streaming support to their distributed caching system

50. MTI - Perencanaan Infrastruktur BH-2002/v1.0/50 Collaborate Patterns  The collaborate pattern involves peer-to-peer communication, usually centered on shared documents or groups of documents  Driven by the need to share and modify calendars, text documents, and design drawings, along with growth of more advanced collaboration techniques using streaming audio and video  True collaboration requires multiple human beings working directly together, through the asynchronous time between their activities  It is essential to have unified, highly centralized, and singular infrastructure solutions  Differentiated patterns in this category include:  Real-time collaborate pattern  Store-and-forward collaborate pattern  Structured collaborate pattern

51. MTI - Perencanaan Infrastruktur BH-2002/v1.0/51 Real-Time Collaborate Patterns  This pattern is quite similar to the stream publish pattern, because both involve enabling real-time transmission of audio and video.  Collaboration implies two-way information exchange  Applications in this category use streaming audio, video, graphics, or text to share information between users.  The communication can flow either through a server or straight from peer-to-peer.  Example: MS NetMeeting, VoIP, IM, any type of videoconferencing

52. MTI - Perencanaan Infrastruktur BH-2002/v1.0/52 Real-Time Collaborate Patterns

53. MTI - Perencanaan Infrastruktur BH-2002/v1.0/53 Real-Time Collaborate Patterns  Benefits:  Lower costs Running real-time collaborate activities over a shared network can enable significant sharing without extra costs.  Better communication Help boost the flow of information and idea, particularly globally.  Customer retention

54. MTI - Perencanaan Infrastruktur BH-2002/v1.0/54 Real-Time Collaborate Patterns  Weaknesses:  Bleeding edge  Plug-in requirements  Security impacts  Network issues

55. MTI - Perencanaan Infrastruktur BH-2002/v1.0/55 Real-Time Collaborate Pattern  Best Practices:  Identify applications that fit this category early and study them carefully  Determine real capabilities—not just application features—based on your existing or planned infrastructure  Estimate the real costs of infrastructure upgrades, and weigh them carefully against expected business benefits  Explore the many options for improving quality, including: oQuality of service (QoS) features in networking equipment and networking services that can help to reduce latency, variation in latency, and jitter oRunning protocols over UDP to reduce some of the latency caused by retransmissions that are required using TCP. oScheduled collaboration using broadcast and multicast technologies, to better control and manage bandwidth demands. oBandwidth upgrades to the existing infrastructure, or dedicated networks for collaborative applications.

56. MTI - Perencanaan Infrastruktur BH-2002/v1.0/56 Real-Time Collaborate Patterns  Futures:  The value of new ways of doing business and interacting with various constituencies will drive continued innovation in this pattern  QoS support within intranets and then Internet makes this pattern more available and affordable  Bandwidth prices will continue to fall  Technology and product options will continue their progress toward cheaper, faster, and better

57. MTI - Perencanaan Infrastruktur BH-2002/v1.0/57 Store-and-Forward Collaborate Patterns  This pattern involves the basic transfer, replication, and storage of files or documents.  Common examples include email, distributed file system, print queues.  The most mature and popular collaborate pattern  This pattern should remain the most decentralized in nature

58. MTI - Perencanaan Infrastruktur BH-2002/v1.0/58 Store-and-Forward Collaborate Patterns

59. MTI - Perencanaan Infrastruktur BH-2002/v1.0/59 Store-and-Forward Collaborate Patterns  Benefits:  Maturity. Mature standards are common in this pattern  Collaborative. This pattern offers simple collaboration solutions that are good enough for many needs  Good model. This pattern can serve as model for maturity in other patterns  Undemanding. The nature of store-and-forward makes network impact light, particularly on WANs  Easy component selection

60. MTI - Perencanaan Infrastruktur BH-2002/v1.0/60 Store-and-Forward Collaborate Patterns  Weaknesses:  Hard to upgrade. Since this pattern is the most distributed, changing standards means changing very many instances of solutions.  Hard to support. Still difficult to provide Help Desk support to a vast group of users.  Data security. Much data can be located on local hard drives.  Slow pace of change.

61. MTI - Perencanaan Infrastruktur BH-2002/v1.0/61 Store-and-Forward Collaborate Pattern  Best Practices:  Establish single standards for e-mail products, calendar products, office automation, and other similar component throughout the enterprise  If you can’t standardize on a single product, use established standards, such as SMTP, S/MIME, and others, to make e-mail system interoperable.  Provide a single file, print, directory, and security solution for this pattern  Provide just a few common desktop configuration and stick to them  Enhance cost recovery by charging a per-desktop fee for all investments in all required systems  Establish centralized control to ensure coordination and standardization across business units. This includes controlling standard schema for directories across multiple organizations, locations, user groups, etc.

62. MTI - Perencanaan Infrastruktur BH-2002/v1.0/62 Store-and-Forward Collaborate Patterns  Futures:  Directory services decoupled from NOS  File systems decoupled from OS (e.g., network-attached printers)

63. MTI - Perencanaan Infrastruktur BH-2002/v1.0/63 Structured Collaborate Patterns  Known as workflow or document management, provides many important integrity-checking features  Requires a longer implementation cycle and is more expensive  Common examples: Lotus notes groupware and workflow application, document management apps, web content management, and shared groupware calendar  Deployed much more centrally that traditional store- and-forward applications

64. MTI - Perencanaan Infrastruktur BH-2002/v1.0/64 Structured Collaborate Patterns  Fig 3.13

65. MTI - Perencanaan Infrastruktur BH-2002/v1.0/65 Structured Collaborate Patterns  Benefits:  Automation/integrity checking. These solutions have strong automation features supported by infrastructure such as check in/check out.  Good opportunity. Thinking of these solutions as a separate pattern may help clarify infrastructure decisions.  Weaknesses:  Uncertainties. Untried solutions require significant testing  Little leverage.

66. MTI - Perencanaan Infrastruktur BH-2002/v1.0/66 Structured Collaborate Pattern  Best Practices:  Employ check-in/check-out document management systems or strong workflow solutions as required  Don’t allow large document collaboration over Internet connection  Extend standard Store-and-Forward solutions as much as possible to take advantage of existing systems and user familiarity. However, don’t hesitate to deploy more structured applications when the business value is clear  Keep solutions as small in scope as possible. The smaller and more localized the workgroup, the easier it is to deploy a successful solution for structured collaboration

67. MTI - Perencanaan Infrastruktur BH-2002/v1.0/67 Structured Collaborate Patterns  Futures:  Convergence of this pattern and 3/N-Tier transact  Becoming more transactional and 3/N-Tier evolving towards workflow and long-lived transactions

68. MTI - Perencanaan Infrastruktur BH-2002/v1.0/68 Adapting Pattern For Your Organization  What Patterns Do I Need?  Extra Patterns Not Covered  Subdividing Patterns  Applying Multiple Patterns

69. MTI - Perencanaan Infrastruktur BH-2002/v1.0/69 What Patterns Do I Need?  First look at your business processes, your applications, and your existing infrastructure solutions and start analyzing where the major patterns lie:  Which patterns do I use a lot?  Which pattern cover the applications most critical to the business?  Any patterns that answer above questions should be automatically entered into your list of required pattern  Some patterns won’t be required at all  Use the 80/20 rule.  Include the smallest number of patterns that provide the maximum value toward infrastructure planning  Try to keep below 10 the number of patterns in which you want to excel.  Focus on those pattern that offer significant ramifications for future application delivery, while spending less time on those pattern that are more mature  Less patterns will require more planning and design to drive toward maturity

70. MTI - Perencanaan Infrastruktur BH-2002/v1.0/70 Extra Patterns Not Covered  Not all business alike, it’s very possible that the patterns discussed here do not include an important aspect of your business  Other infrastructure patterns not reflected here might include:  SCADA  PBX  Your choice of preventative patterns will also be guided by the different service levels your organization needs to achieve in each instance.  Such as developing a “high availability pattern” or a pilot/prototype pattern”

71. MTI - Perencanaan Infrastruktur BH-2002/v1.0/71 Subdividing Patterns  Your business applications might fall into a single pattern, and need to further refine into sub-pattern  Before breaking a pattern apart, consider the following issues:  Is the infrastructure different enough to be worth planning it separately?  Is the infrastructure highly disruptive to the business as a whole or to other sets of applications?  Do you use the applications, and therefore this infrastructure, a lot?  Do you have two parallel product choices that are both commonly used, yet each requires somewhat different infrastructure?  Do you have two instances of a pattern that represent different service-level requirements.

72. MTI - Perencanaan Infrastruktur BH-2002/v1.0/72 Applying Multiple Patterns  Some large-scale applications might require two or more patterns  You shouldn’t feel obligated to run every part of an application on a single infrastructure or pattern  Using pattern helps identify when staging of a single application across multiple infrastructure can help maximize efficiency and minimize redundancy  Example: Web Portal

73. MTI - Perencanaan Infrastruktur BH-2002/v1.0/73 Creating an Infrastructure Portfolio  It’s vital to keep a portfolio of pattern.  Besides patterns you have to maintain platforms, services, projects, projects, processes, and personnel into the portfolio.  A portfolio is composed of four basic parts:  Standards. Standards that control both the external and internal structure of the class of entities stored in the portfolio: oUse case matches oA reference architecture oA reference list or manifest of required components and/or service  Historical information  Inventory template  Actual inventory

74. MTI - Perencanaan Infrastruktur BH-2002/v1.0/74

75. MTI - Perencanaan Infrastruktur BH-2002/v1.0/75 A Template for Standards

76. MTI - Perencanaan Infrastruktur BH-2002/v1.0/76 Putting Applications into the Infrastructure Pattern Portfolio 1.Inventory major and most common application into rough pattern groups  Divide complex application into major use case categories based on who, what, where  Match application use cases with patterns  Focus on essential use case and component variations  Capture description  Capture distinguishing service levels  Create new sub-patterns when two sets of applications in a given pattern have sufficiently distinct service level  A 2-Tier Transact pattern could be divided into 2-Tier Transact Fat client and 2-Tier Thin client

77. MTI - Perencanaan Infrastruktur BH-2002/v1.0/77 Putting Applications into the Infrastructure Pattern Portfolio (cont) 2.Merge use cases that turn out to have no significant difference in service level 3.Analyze results and update draft pattern definitions. Add other descriptive information, conceptual reference architecture 4.Refine the inventory. Capture all component details, standardize terms, capture component de facto standards, and explain deviation 5.Recommendation. Fill in de facto and current standards for component manifest