The Role Of An Architect

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    2 Favorites

    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.  

    + llangitllangit, 2 years ago

    custom

    2121 views, 2 favs, 1 embeds more stats

    Mike Vincent's talk at TechDays Orange Country Nove more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 2121
      • 2052 on SlideShare
      • 69 from embeds
    • Comments 0
    • Favorites 2
    • Downloads 182
    Most viewed embeds
    • 69 views on http://blogs.msdn.com

    more

    All embeds
    • 69 views on http://blogs.msdn.com

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories