The Role Of An Architect
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

The Role Of An Architect

on

  • 10,455 views

Mike Vincent's talk at TechDays Orange Country November 2008

Mike Vincent's talk at TechDays Orange Country November 2008

Statistics

Views

Total Views
10,455
Views on SlideShare
9,690
Embed Views
765

Actions

Likes
4
Downloads
419
Comments
0

3 Embeds 765

http://blogs.msdn.com 558
http://softarchitect.wordpress.com 197
http://www.slideshare.net 10

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The Role Of An Architect Presentation Transcript

  • 1. The Role of an Architect Mike Vincent http://mvasoftware.com MSDN Developer Track
  • 2. Text and Wireless info
    • Survey
        • Bluetooth opt in
        • Text “survey” to 95495
        • Privacy policy
    • Resources on Demand
        • Text “ThursATwo” to 95495
        • Respond with preferred email address
        • Resources/links from this session will be pushed to you via email
    • Wireless internet available in the lobby area
    • SSID: “TechDays”, no passcode
    • Provided by iBahn, hospitality broadband leader
    • Internet kiosks also available in the registration area after check-in
    • Text Messaging
    • Wireless Internet
  • 3. Today’s Outline
    • Why architects exist
    • What architects do
    • Why organizations need them
    • What one needs to know to be one
    • Where we are going as a profession
  • 4. The Role of an Architect
    • The role of the IT architect is to solve a problem by defining a system that can be implemented using technology.
    • Good architects define systems by applying abstract knowledge and proven methods to a set of technologies with the goal of creating an extendible and maintainable solution.
  • 5. The Role of an Architect
    • “ Architects are seasoned, well-balanced professionals with good analytical and communication skills that raise the long-term success of IT projects.
    • “ There are four core tenets I seek in architects in order to call them rock-solid role models in IT architecture profession:
      • They should be actively practicing architects
      • They should  communicate up (to business owners), down (to technologists), and across (to other architects)
      • They should bring predictability and repeatable success to IT projects
      • They should have a vendor-neutral approach when creating architectures”
    • -- Miha Kralj, Architect on Microsoft’s Architecture Strategy Team
  • 6. The Role of an Architect
    • “ An Architect provides the bridge and translation point between a business owner’s vision/intent and a technologists implementation of a system.
    • They are responsible for defining and selling the shared system vision, designing the structure and cross cutting concerns of the system, and steering and measuring the ultimate implementation of the system to deliver business value.”
    • -- Graham Elliott, Architect with Microsoft Consulting Services in Australia
  • 7. Architect Roles
    • Enterprise
    • Solution
    • Software
    • Technical
    • Information
    • Database
    • IT
    • Business
    • Security
    • etc.
  • 8. Architect Roles
    • Enterprise
    • Solution
    • Software
    • Technical
    • Information
    • Database
    • IT
    • Business
    • Security
    • etc.
  • 9. Compare to Building Architecture
    • Gather requirements, Understand client needs
    • Conceptualize
    • Create design
    • Refine with client
    • Prepare detailed plans and specifications
    • Act as advocate of client in execution of design
    • Gather requirements, Understand client needs
    • Conceptualize
    • Create design
    • Refine with client
    • Prepare prototype and detailed design
    • Act as advocate of client in execution of design
    • Building Architect
    • IT Architect
  • 10. A Lot of Similarities, What’s Different
    • Work Down
    • Value Up
  • 11. What We Do Definition Delivery
  • 12. What We Do - Definition Definition Management of non-functional requirements Architecture definition Architecture collaboration Technology selection Architecture evaluation
  • 13. What We Do - Definition Definition Management of non-functional requirements Architecture definition Architecture collaboration Technology selection Architecture evaluation
  • 14. What We Do - Definition Definition Management of non-functional requirements Architecture definition Architecture collaboration Technology selection Architecture evaluation
  • 15. What We Do - Definition Definition Management of non-functional requirements Architecture definition Architecture collaboration Technology selection Architecture evaluation
  • 16. What We Do - Definition Definition Management of non-functional requirements Architecture definition Architecture collaboration Technology selection Architecture evaluation
  • 17. What We Do - Definition Definition Management of non-functional requirements Architecture definition Architecture collaboration Technology selection Architecture evaluation
  • 18. Definition
  • 19. What We Do - Delivery Delivery Ownership of the bigger picture Leadership Design, development and testing Coaching and mentoring Quality assurance
  • 20. What We Do - Delivery Delivery Ownership of the bigger picture Leadership Design, development and testing Coaching and mentoring Quality assurance
  • 21. What We Do - Delivery Delivery Ownership of the bigger picture Leadership Design, development and testing Coaching and mentoring Quality assurance
  • 22. What We Do - Delivery Delivery Ownership of the bigger picture Leadership Design, development and testing Coaching and mentoring Quality assurance
  • 23. What We Do - Delivery Delivery Ownership of the bigger picture Leadership Design, development and testing Coaching and mentoring Quality assurance
  • 24. What We Do - Delivery Delivery Ownership of the bigger picture Leadership Design, development and testing Coaching and mentoring Quality assurance
  • 25. Delivery
  • 26. Choosing the Right Tools for the Job
    • Managing your SDLC process
    • Consider a development framework
    • COTS components
    • Ajax
    • Silverlight
    • Dynamic Languages
    • Functional Languages
    • LINQ
    • Do you need a rules engine?
    • Connectivity
    • Messaging
    • Data transformations
    • Do you need workflow?
    • Scalability
    • Security
  • 27. Managing Your SDLC Process
    • Software architecture is more than an overall guide to system design and construction for developers. As architects we have a responsibility to keep IT and the business stakeholders requirements in alignment.
    • Software Development Life Cycle process management
      • Why
      • Benefits
  • 28. Managing Your SDLC Process
    • Process methodology
      • CMMI
      • Agile
      • RUP
      • Scrum
      • Waterfall
  • 29. Agile MSF
  • 30. Consider a Development Framework
    • A Framework facilitates software development with a degree of architectural consistency by allowing developers to focus on solving business problems rather than spending time and effort on low level ‘plumbing’ issues.
  • 31. Development Frameworks
    • Foundation classes
    • Application blocks
    • Software factories
    • Commercial frameworks
    • Open source frameworks
  • 32. Development Frameworks
    • Solve specific problems
    • May be broadly or narrowly focused
    • When adopting a framework you should understand and agree to play by the rules
    • Can provide more than just plumbing
      • Rapid development (although most frameworks are not necessarily RAD environments
      • Development consistency in your shop
    • One size does not fit all
  • 33. COTS Components and Applications
    • Commercial off the shelf components provide a broad and rich variety of pre built and tested tools, components and utilities.
    • Speed up development
    • Provide users with rich functionality
    • Solutions to common requirements
    • Solutions to very specific requirements
    • An ERP system
  • 34. The Right Technology Mix
    • LINQ
    • Ajax
    • Silverlight
    • Dynamic Languages
    • Functional Languages
  • 35. Do You Need a Rules Engine
  • 36. What is a Rules Engine
    • A software system that contains rules on behalf of another system
    • Business rules guide the decision-making behavior of all business processes
    • Business rules are the conditional criteria against which factual variables are evaluated to determine an appropriate business action.
    • Provides a means to classify and manage rules in a centralized location.
  • 37. Why Use A Rules Engine
    • Change
    • Maintainability
    • Separate rules from implementation methods
    • Extensibility of requirements
    • Ownership of rules
    • Preserve rule comprehensibility
    • Enable dynamic binding
    • Don’t have to recompile to implement changes
  • 38. Connectivity
    • Business needs
      • Support Process Improvement
      • Build business
      • Add partners
      • Grow geographically
      • Be agile
      • Get ahead of the competition
      • Respond to change
      • Reduce total cost of ownership
      • Reduce and control operations costs
  • 39. Connectivity – SOA, Why?
    • Improved adaptability
    • Improved agility
      • Respond to business needs in near real-time
    • Functional reusability
      • Eliminate the need for large scale rip and replace
    • Independent change management
      • Focus on configuration rather than programming
    • Interoperability instead of point-to-point integration
      • Loosely coupled framework, services in network
    • Orchestrate rather than integrate
      • Configuration rather than development to deliver business needs
  • 40. Shift to a Service-Oriented Architecture
    • Function oriented
    • Build to last
    • Prolonged development cycles
    • Process oriented
    • Build to change
    • Incrementally built and deployed
    From To
    • Application silos
    • Tightly coupled
    • Object oriented
    • Known implementation
    • Orchestrated solutions
    • Loosely coupled
    • Message oriented
    • Abstraction
  • 41. SOA Start-up Checklist
    • Decide What Functionality to Expose
    • Understand Your Business
    • Invest in SOA Management or an ESB
    • Keep a Close Eye on Underlying Application Platforms
    • Plan for a Registry and Repository
    • Consider Hardware Acceleration
    • Decide if you Need a Firewall
  • 42. Messaging
    • How do I integrate multiple applications?
      • File transfer
      • Shared Database
      • Remoting
      • XML
  • 43. Messaging - Desirable Characteristics
    • Frequent
    • Immediate
    • De-coupled
    • Asynchronous
    • Reliable
    • Efficient
  • 44. Messaging – Basic Concepts
    • Channels
    • Messages
    • Pipes and Filters
    • Routing
    • Transformation
    • Endpoints
  • 45. Messaging with an Enterprise Service Bus
    • Use messaging to transfer packets frequently, immediately, reliably and asynchronously using customizable formats
  • 46. Data Transformations
    • Data transformation is the mapping and conversion of data from one format to another
      • XML-to-XML
      • XML-to-nonXML
      • nonXML-to-XML
    • Typically implemented with standards based tools
      • XSLT
      • XQuery
  • 47. Data Transformations
    • Powerful GUI based transformations tools
      • Mappers – Drag and Drop
      • Code – Type and Type quote.name = priceQuoteDoc.customerName;
        • quote.address = StringFormat(“{0} {1} {2} {3} {4}”, priceQuoteDoc.shipAddress.street, priceQuoteDoc.shipAddress.city, priceQuoteDoc.shipAddress.state, priceQuoteDoc.shipAddress.zip );
  • 48. Data Transformations
    • Complex Mapping
  • 49. Data Transformations
    • Transformations
      • Batch
      • De-batch
      • Legacy
      • Standards
        • EDI HL7 HIPPA SWIFT
      • Internal/Canonical
    • Exposed to Business
  • 50. Orchestration and Workflow
    • Manage process execution
      • Sequential
      • Parallel
      • Long running
    • Manage human workflow
      • Process interaction
  • 51. Workflow Rules-driven Activities Step2 Step1 Rule1 Rule2 Data Rules + data state drive processing order
    • Data-driven
    • Simple Conditions, complex Policies
    • Constrained Activity Group
    State Machine Workflow Event Event External events drive processing order
    • Reactive, event-driven
    • Skip/re-work, exception handling
    • Graph metaphor
    Sequential Workflow Step1 Step2 Sequential structure prescribes processing order
    • Prescriptive, formal
    • Automation scenarios
    • Flowchart metaphor
    State2 State1
  • 52. Scalability
    • Scale out
    • Scale up
    • Use web services to scale
      • Windows Azure
  • 53. Security
    • Good security is not a bolt on
    • Platforms and components you use contribute to the overall security of your solution
    • You are responsible for the security of your integration
    • Review with best practices
  • 54. Security – Frame of Reference
    • Configuration Management
    • Data Protection in Storage and Transit
    • Authentication
    • Authorization
    • User & Session Management
    • Data Validation
    • Error Handling & Exception Management
    • Auditing and Logging
  • 55. Why Organizations Need Us
  • 56. Why Organizations Need Us
    • A successful architecture forms the platform for strategic advantage
  • 57. Why Organizations Need Us
    • A successful architecture forms the platform for strategic advantage
      • Lack of architecture bonds the organization inescapably to its past
  • 58. Why Organizations Need Us
    • A successful architecture forms the platform for strategic advantage
      • Lack of architecture bonds the organization inescapably to its past
      • Legacy systems are expensive and hard to change
  • 59. Why Organizations Need Us
    • A successful architecture forms the platform for strategic advantage
      • Lack of architecture bonds the organization inescapably to its past
      • Legacy systems are expensive and hard to change
      • But replacing them threatens the very "life" of the organization
  • 60. Why Organizations Need Us
    • Symptoms of architectural decay
  • 61. Why Organizations Need Us
    • Symptoms of architectural decay
      • Brittle monolithic systems
  • 62. Why Organizations Need Us
    • Symptoms of architectural decay
      • Brittle monolithic systems
      • Silo applications
  • 63. Why Organizations Need Us
    • Symptoms of architectural decay
      • Brittle monolithic systems
      • Silo applications
      • Long and unpredictable development times
  • 64. Why Organizations Need Us
    • We need architecture to
  • 65. Why Organizations Need Us
    • We need architecture to
      • Break the chains of our corporate legacy
  • 66. Why Organizations Need Us
    • We need architecture to
      • Break the chains of our corporate legacy
      • Build systems that fit the environment
  • 67. Why Organizations Need Us
    • We need architecture to
      • Break the chains of our corporate legacy
      • Build systems that fit the environment
      • Adapt with the environment as it changes
  • 68. Why Organizations Need Us
    • Whether we seek to lead through innovation, customer intimacy or operational excellence, Architecture is the essential foundation for
  • 69. Why Organizations Need Us
    • Whether we seek to lead through innovation, customer intimacy or operational excellence, Architecture is the essential foundation for
      • Agility
  • 70. Why Organizations Need Us
    • Whether we seek to lead through innovation, customer intimacy or operational excellence, Architecture is the essential foundation for
      • Agility
      • Responsiveness
  • 71. Why Organizations Need Us
    • Whether we seek to lead through innovation, customer intimacy or operational excellence, Architecture is the essential foundation for
      • Agility
      • Responsiveness
      • Effectiveness 
  • 72. Why Organizations Need Us
    • Architecture
  • 73. Why Organizations Need Us
    • Architecture
      • Addresses complexity
  • 74. Why Organizations Need Us
    • Architecture
      • Addresses complexity
      • Leaves the team mind-space open to innovation
  • 75. Why Organizations Need Us
    • Architecture
      • Addresses complexity
      • Leaves the team mind-space open to innovation
      • Is the enabler for reliable systems
  • 76. Why Organizations Need Us
    • Architecture
      • Addresses complexity
      • Leaves the team mind-space open to innovation
      • Is the enabler for reliable systems
      • Is solutions developed in "Internet time"
  • 77. Why Organizations Need Us
    • Architecture
      • Addresses complexity
      • Leaves the team mind-space open to innovation
      • Is the enabler for reliable systems
      • Is solutions developed in "Internet time"
      • Is systems that scale
  • 78. Why Organizations Need Us
    • Architecture
      • Addresses complexity
      • Leaves the team mind-space open to innovation
      • Is the enabler for reliable systems
      • Is solutions developed in "Internet time"
      • Is systems that scale
      • Is systems that "Wow" customers with an individualized experience
  • 79. IT Architect Skills
  • 80. IT Architect Skills
    • Domain Knowledge
      • Horizontal
      • Vertical
  • 81. IT Architect Skills
    • Domain Knowledge
      • Horizontal
      • Vertical
    • Conceptual Thinking
      • Communication
  • 82. IT Architect Skills
    • Domain Knowledge
      • Horizontal
      • Vertical
    • Conceptual Thinking
      • Communication
    • Patterns
      • More communication
  • 83. IT Architect Skills
    • Domain Knowledge
      • Horizontal
      • Vertical
    • Conceptual Thinking
      • Communication
    • Patterns
      • More communication
    • Technical
      • Code
      • YAGNI
      • Understand where technologies are applicable
  • 84. Soft Skills
  • 85. Soft Skills
  • 86. Architect Competency Domains
  • 87. Technology
  • 88. Business Strategy
  • 89. Organizational Politics
  • 90. Consulting
  • 91. Leadership
  • 92. Building Our Profession
      • The IT Environment
      • Business Technology Strategy
      • Design
      • Human Dynamics
      • Quality Attributes
      • Software Architecture
      • Infrastructure
    • http://www.iasahome.org/web/home/skillset
  • 93. Body of Knowledge - ArcBOK
  • 94. Education
    • Formal IT Architecture education is evolving
      • We are a few years away from degree programs
      • Extended education certificate programs
      • IASA
        • Fundamentals of IT Architecture Courses
        • Software Architecture Courses
        • Infrastructure Architecture Courses
        • Business Architecture Courses
    • http://www.iasahome.org/c/portal/layout?p_l_id=PUB.9871.49
  • 95. Certification
    • Microsoft Certified Architect
    • The Open Group Architecture Framework
    • Control our professional destiny
      • Will we be regulated?
      • Influence and guide regulators to optimal decisions
      • Avoid knee-jerk, politically guided decisions in haste
  • 96. Call to Action
    • Get involved with a local user group http://SoCalDotNetArchitecture.org
    • Get involved with a professional organization http://www.IASAhome.org
    • Contribute to building ArcBOK, email miha.kralj@microsoft.com
  • 97. Wrap-up
    • MSDN Architecture Center http://msdn.microsoft.com/en-us/architecture/default.aspx
    • The Role of an Architect http://msdn.microsoft.com/en-us/library/cc505966.aspx
    • The Role of the Architect http://www.bredemeyer.com/pdf_files/role.pdf
    • IASA http://www.iasahome.org
    • SoCal .NET Architecture http://www.socaldotnetarchitecture.org
    • Architect Soft Skills http://dobbscodetalk.com/index.php?option=com_myblog&show=Architect-Soft-Skills.html&Itemid=29
    • The Role of a Hands-on Software Architect http://www.codingthearchitecture.com/pages/book/role.html
  • 98.