Friday, July 30, 2010

Few useful resources/links on web on aspiring Architects

This blog is in reply for all the mails I get for links and reading material for an aspiring architect.
Architecting has several aspects:

  • Modeling (How to create Architecture document, describe various views shown above)
                 - 4+1 Rational View with 5 views is most common http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf
                 -Visual Architecting  http://www.bredemeyer.com/pdf_files/WhitePapers/VisualArchitectingProcess.PDF

Architect technical demonstrates solves how significant use-cases are being handled by his architecture. (details in text below)

    • This is very specific to problems at hand. Also depends on whether you are custom building it or using a product. If product, then you need to show how it is integrated.

    • Integration Architecture: how would system integrate with applications or packages being selected for usage.

    • Information Architecture: how is the screen or user interface desinged and navigated to allow access to the system 

  • End-2-End System flow

    • Logical Architecture, Layer architecture (Frameworks at each tier is shown and explained and their integration).\

    • Component Architecture; significant components and their relationships.

  • Messaging Architecture: if the system is based on the messages.

  • Service Architecture: if the system is based on SOA paradigmn.

  • Non-Functional Requirements

    • Performance - Caching, Capacity planning

    • Scalability - clustering, Server Farms …

    • Security – Single Sign-on, Windows Security Architecture, Windows Authentication, Kerboros, Active Directory …
Microsoft Application Architecture Guide at msdn site: http://msdn.microsoft.com/en-us/library/dd673617.aspx  is a very good resource which talks on all these things:

- Principles of architecture
- Patterns and styles
- Guideline for layers and components
- Quality Attributes
- Crosscutting concerns
etc.


 Some other architecture sites from Microsoft on internet:
A very good source of learning is learning from the architecture of other applications ‘architectures and patterns (like open source or code in codeplex) .
Copying and understanding from successful applications’ architecture is best form of learning. These applications may already have some concerns in the system at hand. So understand how have they solved their problems and apply them intelligently.
Then there are other sites based on the some specific area of architecting:

  • Sharepoint http://msdn.microsoft.com/en-us/library/bb892188(v=office.12).aspx

  • Biztalk (SOA) http://msdn.microsoft.com/en-us/library/aa562161(v=BTS.10).aspx

  • Cloud Architecture (Azure) http://wag.codeplex.com/
Some sites describing architecture in general on main techniques of Architecture Modeling:
If somebody searches on google there would ample material for learning architecture but becoming architect is gradual process ...
Developer - > Senior Developer -> Module Designer -> Project Designer-> Architect
All the roles above are problem solvers. Only the problem get complex in size and scale as we move left to right…
However, there is no time limit for any of these roles because someone who have done a very complex project in one role and is mature can become architect faster than a person who is doing routine technical jobs and does not get involved in complex technical scenario.
Developer
Developer's focus is only his particular program. Senior Developer looks at more complex and larger programs and module. He may only focus on back-end or front-end program. Like writing a class function which takes the inputs like Account# and gives back the interest calculated on his account. So developer would write a program which reads in account balance and calculate the interest (monthly/yearly) based on applicable interest method. For this he makes database calls, does calculations and returns the interest.
Designer
Designer starts designing the module/system, he is looking at much higher level than programmer. He is looking at how program written by developers will interact with other programs to provide a functionality end-2-end. He may be designing the entire module of interest system.
His work starts much earlier than developer because he designs the entire module and envisions the required classes and functions which will make the interest module functioning. It is his inputs which are used by the developer for developing the program.
Designer does more abstract thinking. He thinks at the module level. He does not think about the java programming of multiplication, database calls to calculate interest. However, he does design and check feasibility and availability of required data.
He envisions the various classes and entities like Accounts, Account Types, Balances (Monthly Avg. Balance, Interest Methods etc.) , Interest Method, Interest Accrual, Interest Application ….
Architect
Architect does works with much further abstraction. He thinks at much higher level. His work starts earlier than designer because he is checking the feasibility of the entire system. He tries to think of all the risks and technical aspect of architectural significance. He finds and articulates solution of all these aspect of significance.
What is significant depends on what has not been tested or not know. Reading from a file is not of significance because any java programmer can do it and has widely known solution. But reading from file which is located in “cloud or hosted in remotely” with some aspect of synchronization and concurrency becomes significant, if programmer does not know about it. So architect would take this as significant use case and provide solution for it in his architecture document.
Architecture models architecture from all views (Developer, Designer, Functional, Deployment, and Process) because his document is guiding framework for all these people.
Architect by providing solution for significant technical aspect convinces development team of the feasibility of his solution. He gives confidence to the development team that there is no roadblock at later stage. He provides guidance framework for designers by providing the significant component in the system and their relationship. He also provide end-2-end from user-interface to back-end system functioning and data flow.
Architecture document’s Deployment diagram advices the system administrator about the hardware and server configuration. Project Manager can find the entire system complexity and size from the architecture document.
Functional people can see how their significant use cases are being fulfilled and are convinced.
So, all risks are mitigated and presented and discussed to the project team for development. The risks which are mitigated are validated by small POCs.

No comments:

Post a Comment