Wednesday, November 21, 2007

TAGS Training

11/21/2007

Technology Architecture Grooming School



Context Settings


Curriculum

MIT - ASDA

TAGS – Technical Architecture Grooming School

TAPS (2 days) – Technical Architecture Principle school

TADS/TASA (5 days) - Technical Architecture Design School

APW – Architecture Principle Workshop

MTA – Master Technical Architecture


Role of an Architect


Idea of how something should be accomplished.

Defines how the pieces put together.

Role of each pieces.

How they work together.


Architecture Vs Software Design

“Architecture is a design but not all the design is architecture.”


Architecture

  • Stability against forces.

  • Overall structure

  • Ground Load

  • Technology Choices


Design

  • Interior layout

  • Furnishings

  • Rooms and amenities

  • Look and feel


Discipline of Architecture

- Understand the problem.

- Define the structure for a solution.

- Decompose the problem into smaller manageable pieces.

- Resolve the details of the smaller pieces.

- Ensure that each pieces fit in an integrated manner to complete the overall solutions.

- Ensure that solution meets expectations, functional and technical requirements.

-Ultimately solve the problem and achieve the initial version.


Systems Development Engagement


Bigger the engagements, sharper the skills required for Technical Architects to solve complex problems.


Role and Relationships


Manages the analysis, design, build and integration of the solution components.


Technical Architects Responsibilities


Analyze

  • Define application and technical requirements.

  • Define the structure of the application and technical arch.

  • Ensure the structure meets the business requirements and performance goals

  • Ensure the technical direction is consistent with the client’s log term direction.


Design

  • Design development operations and execution environments

  • Maintain quality, development and change control processes

  • Drive the design of application data and UI classes and components via the application architecture specification.

  • Ensure training and performance support service introduction and deployment are adequately considered against the design

  • Decide on hardware, networking systems software and security.


Build and Test

  • Iteratively improve environment designs

  • Maintain quality development and change control processes

  • Conduct or administer code reviews, as appropriate

  • Drive issue management and resolutions.

  • Assist in deployment planning.

  • Develop technology policies and procedures.


Design patterns are guidelines of how you solve business problems.”


Characteristics of Successful Technical Architects


  • A solid foundation of coding, testing and development skills.

  • A broad skill set, in addition to deep skills in specific technology.

    • They know what they don’t know

  • Good understanding of architectural principles.

  • Ability to network and sought out for their capabilities

  • Manage team and projects effectively.


Architecture Types


Application Architecture

  • maps the functional requirements to discrete software solutions it defines the technical services that are needed by application.


Technical Architecture

  • refers to the blueprint or design of technical services that are required to support an application.


Technical architect is typically responsible for both technical architecture and application architecture.

Case Study - 1


Business Requirements:

Financial Services Client, to build a intranet based solution with following requirements

  • Company Info and news

  • Employee Tools

    • Pay slips

    • Vacation Policy

    • Form 16 A

  • News feeds (top news relevant to industry)


Functional/Technical Requirements:

  • Browser accessible

  • Leverage existing infrastructure.

  • Should be developed fully by partner.


Thoughts On:

  1. Application Architecture

  2. Non functional requirements

  3. Development environment


Team Members:

Mihir.Anil.Mone

Veera.Mangipudi

Sudhir.Kesharwani



The Ilities


Architectural goals are often refereed to as the “-ilities”, since they end with the word “ility”

    • Scalability

    • Security

    • Performance


Performance

Measures the speed with which a single request can be executed.

Performance Drivers

  • Reduced response time

  • Availability

  • Internet traffic


Best Practices

    • Benchmark early against peak loads and worst case configurations

    • Can I get the individual response times I need ?

    • 80:20 rule - do the important things fast, not everything.

    • Does the required transactional volume fit on the platform?

    • Typically need a local or remote reference data cache

      1. Key trade off is performance versus ability to keep cache current.

      2. Portioning data and executing parallel job streams

    • Performance is driven by bottlenecks.

    • Target bottleneck by

      1. Doing expensive things (like I/O) less frequently.

      2. Doing repetitive things more intelligently; use caching.


Performance Improvements:

    • Tuning the runtime for better heap management, memory management accelerators.

    • Concurrency through multithreading

    • Asynchronous usage patterns

    • Entity caching

    • Minimize individual database operations, batch up requests

    • Optimize log settings.


Scalability

Scalability is related to the ability of the application to respond to multiple separate interactions. Under these circumstances

    • Is the performance of the application downgraded?


Some patterns for scalability

    • Connection pooling in JDBC

    • Object pooling

    • User Session / State caching

    • Sever affinity and sticky sessions

    • Clustering and load balancing of servers (web, application and database)




Security

-Different user levels, allowing access to different parts of the application.

- Layers of Security

> Authentication, authorization, access auditing

> Physical vs. electronic

> Systems administration

> Encryption services

> Fraud services

> balance risk/reward on investment

- Build security in from day one


- Considerations

> International issues

> Separation of duties

> A security policy

> Security Standards

> Administration Procedures

> Testing procedures

> Training programs

> Consequences of not getting the right security.


Resilience

    • What happens to working storage at a checkpoint? To files? To databases?

    • Design for failure, allow processing to continue if at all possible and provide detailed and accurate diagnostics.


Interoperability

Do all of the components work together smoothly? Interoperability is ensuring that all the parts of the systems work together. Failure to address interoperability issues will reduce your ability to run, maintain and extend the architecture.


    • What types of bridges are required to connect the technologies? Are they readily available?

    • Have you verified all vender claims?

    • Have you prototyped anything new or complex?

    • Conformance to standards

    • Plug and play

    • Test under production like environment

Flexibility

Can the technical architecture change quickly to meet new business requirements>

    • Use standard design methods, programming techniques and tools to simplify maintenance.


Availability

Maintainability

    • Consider configuration management and application packaging early.

    • Consider distribution of software updates.

Architectural Styles


The word architecture is both about designing something and about making, building or constructing something

Therefore architecture can be thought of in a theoretical and a practical basis


Architecture is about designing and building something from a set of basic components, and also about the interrelations among the components


Client/Server Architecture

Support a style of computing where processes on different machines communicate using messages.

  • The “client” processes delegate business functions or other tasks to one or more server processes.

  • The server processes respond to messages from clients.

  • Business logic can reside on both client and server.

  • Clients are typically PCs or workstations with a graphical user interface

  • Servers are usually implemented on UNIX, NT or mainframe machines.

  • For e.g. Desktop applications.



Integration Architecture and Patterns


Getting different application talk together using common language.


File Transfer:

Have each application produce files of shared data for others to consume, and consume files that others have produced.


Shared Database

Have the applications store data they wish to share in a common database.


Remote Procedure Invocation

Have each application exposes some of its procedures so that they can be invoked remotely, and have applications invoked those to run behavior and exchange data.


Messaging Framework (Point to Point Messaging)

Each application talks to its collaborators via a dedicated pipe, ensures that only one system gets the message, useful for workflow.


Publish / Subscribe Messaging

Application publishes a message to a queue, other applications subscribe to the queue, useful for event propagation.


Message Broker

Message Broker ca receive messages from multiple destinations, determine the correct destination and route the message to correct channel.


Emerging Integration Architecture

And EAI solution serves as a centralized location for development and control of applications, enabling visibility of information across the enterprise.


Advantages:

  • Hum/Spoke of bus messaging architecture reduces number of connection

  • Loose coupling of integrated applications

  • Pre build adapters reduce efforts to integrate with packaged applications.

  • Reusable data/message transformation and formatting functions

  • Near real time and batch integration

  • Inter enterprise connections

  • Central Control of multi step business processes across multiple application.


Data Architecture

Data architecture focuses on both tactical (short term) and strategic (long term) uses of data at both the application and enterprise wide levels


  • It is not just the “documentation that the DBA has to do”

    • Logical Data Modeling

    • Physical Data Modeling

    • Sizing, Naming Standards

  • This is not “design- build-run-away” task.

  • At the enterprise level is about data mastery and data flow.

  • More and more this involves XML schema & message definitions, data mappings, message transformation and common data definitions.


What is not covered in this

  • Development architecture, Operational Architecture and execution architecture

  • Infrastructure Architecture

  • Architectural Frameworks

  • Other architectural styles

    • Portal

    • Data Warehousing

No comments: