mti - perencanaan infrastruktur bh-2002/v1.0/1 adaptive infrastructure: identifying and using...
TRANSCRIPT
MTI - Perencanaan InfrastrukturBH-2002/v1.0/1
Adaptive Infrastructure:Identifying and Using Pattern
Sjarif Abdat ([email protected])
Universitas Indonesia
MTI - Perencanaan InfrastrukturBH-2002/v1.0/2
Reference: The Adaptive Enterprise: IT Infrastructure Strategies to Manage
Change and Enable GrowthBruce Robertson and Valentin SribarAddison Wesley, 2002
MTI - Perencanaan InfrastrukturBH-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.
MTI - Perencanaan InfrastrukturBH-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.
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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?
MTI - Perencanaan InfrastrukturBH-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 patternsApplications with read-only data, such as online marketing information
Collaborate patternsApplications 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.
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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.
MTI - Perencanaan InfrastrukturBH-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.
MTI - Perencanaan InfrastrukturBH-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?
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-2002/v1.0/20
2-Tier Transact Pattern
Weaknesses: Lack of scalability Security vulnerabilities Sourcing limitation Presentation limitation Lack of API Hidden Cost
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-2002/v1.0/25
3/N-Tier Transact Pattern
Benefits: Scalability. Distributing the processing load on multiple
server tiers provides significant scalabilityo Requires 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
o Reduces the cost of EAI because of sharing APIs between applications reduces the time and expense required to integrate the apps
MTI - Perencanaan InfrastrukturBH-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.
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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.
MTI - Perencanaan InfrastrukturBH-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:o Increased redundancyo Better performanceo Easier management
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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:
o Network load balancer and multi-site balancingo Compressiono Caching (reverse caching in DC, client caching,
intermediate ISP caching)o Content delivery network (CDN) services like Akamaio Traffic or rate shapping
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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.
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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 choiceVendor solution are coalescing slowly, which makes specifying solutions easier to do
MTI - Perencanaan InfrastrukturBH-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 demandE-Business or consumer-focused sites normally have an unknown external user base.
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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 communicationHelp boost the flow of information and idea, particularly globally.
Customer retention
MTI - Perencanaan InfrastrukturBH-2002/v1.0/54
Real-Time Collaborate Patterns
Weaknesses: Bleeding edge Plug-in requirements Security impacts Network issues
MTI - Perencanaan InfrastrukturBH-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:
o Quality of service (QoS) features in networking equipment and networking services that can help to reduce latency, variation in latency, and jitter
o Running protocols over UDP to reduce some of the latency caused by retransmissions that are required using TCP.
o Scheduled collaboration using broadcast and multicast technologies, to better control and manage bandwidth demands.
o Bandwidth upgrades to the existing infrastructure, or dedicated networks for collaborative applications.
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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.
MTI - Perencanaan InfrastrukturBH-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.
MTI - Perencanaan InfrastrukturBH-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)
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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.
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-2002/v1.0/68
Adapting Pattern For Your Organization
What Patterns Do I Need? Extra Patterns Not Covered Subdividing Patterns Applying Multiple Patterns
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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”
MTI - Perencanaan InfrastrukturBH-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.
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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:
o Use case matcheso A reference architectureo A reference list or manifest of required components and/or
service Historical information Inventory template Actual inventory
MTI - Perencanaan InfrastrukturBH-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
MTI - Perencanaan InfrastrukturBH-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