Archive

Archive for the ‘Architecture’ Category

Layers of Architecture

October 16, 2009 Leave a comment

There are tons of architects out there today. It seems when you’ve spent enough time as a developer, you end up becoming an architect.  Architecture is not just the next step in a developers career. There are whole new disciplines and methodologies applicable to architecture. That said here are the common levels of architecture.

Enterprise Architecture (planner)

Enterprise architecture is a high level field that concentrates on how the various domains or subject areas interact. This layer spends even more time focusing on how technology will be utilized in the future, and governing how it is used today. Enterprise architects work to create technology roadmaps and work with the business to plan for the implementation. Enterprise architects create technology projects. It is at this layer where frameworks like TOGAF and taxonomies like Zachman come into play. This layer view the enterprise as a holistic entity.

 

Solution Architecture (designer)

A solution is an answer to a question. The question in this case is typically an IT project. The solution architect’s primary objective is to design a solution that meets the projects requirements and also falls in line with the domain and enterprise architecture guidelines. The solution architect is responsible for coordinating with multiple domain architects to design the most appropriate solution. A solution architect may interact with domain architects in infrastructure, web services, data management, and so on. During the course of the project a solution architect will typically create many work products either for communicating the solution to a governance board, to explain the implantation to a developer and various other uses. These work products are eventually owned by the domain architect as codified knowledge of the system after the project implementation.

 

Domain Architecture (owner)

A domain is an area of focus. Domain architects are primarily focused on maintain a specific area of technology or a specific application. These architects are the owners and gatekeepers for a specific area. The work in this area is primarily concerned with the current state of the system. These architects are charged with managing the knowledge for their area. These architects are also responsible for keeping up to date on future projects related to the domain and guiding the designs to meet the overall objectives of the domain. A successful domain architect will know that a future project will require x functionality. When an active project is debating between two possible implementations, the domain architect will be able to guide solution toward the best of the two solutions that meet the future goals.

 

Application or System Architecture(builder)

The application or system architect is primarily focused on the implementation at hand. This is the most detailed level of architecture. An application architect, for instance, would be concerned with the most appropriate design pattern to use in a certain programming situations. These tend to evolve from the most advance developers and engineers. The primary focus here is to implement the best solution for a specific task. Work products that may be produced during this layer are primarily used to communicate to the developers or implementers. In many co-located environments a lead developer often fills this role and very few work products are actually produced. Instead the team may utilized whiteboards or code stubs to communicate the implementation. For larger more dispersed projects, or for outsourced solutions, the application or system architect has a more demanding role for providing detailed implantation instructions. 

 

Conclusion

The various layers of architecture are not meant to be isolated entities. In most situations one architect will fill multiple roles at various levels. Each layer has a unique focus. Understanding the layers helps clarify responsibilities, activates and deliverables. From a career development standpoint individuals can use the layers as the basis for a personal gap analysis and learning plan.

 

I look forward to reading your thoughts and comments.

 

Best of luck in all your endeavors.

What is Architecture

September 29, 2009 Leave a comment

image

The word architect, and architecture are thrown around a lot and are frequently misused. There a frameworks, methodologies, classifications that get into extreme detail on what architecture is.  Understanding what architecture means is valuable to excel in a current architect role or for use in career planning and development. The following distills a variety of sources such as Zachman and TOGAF into a more pragmatic summary of architecture.

Architecture (noun)

Units of technology have defined sets of architectural elements. These elements can be applied at any level from a macro / enterprise perspective, down to the view of a simple utility. All technology units contain the following architectural elements.

  • Scope Vision Mission Purpose
  • Business Process and Models
  • Information Architecture (Applications)
  • Technologies
  • Operation

Architecture (verb)

The practice of architecture is applied with multiple perspectives. Each perspective takes into account the elements from the others, yet has a unique focus and function.

  • Enterprise Architecture
    • Strategy & Direction
      • Mission / Vision
    • Guidance & Governance
      • Architectural Principles
      • Architectural Processes
  • Domain Architecture
    • Knowledge Management
    • Run Time / Operation
  • Solution Architecture
    • Tactical
    • Project

Code Quality with Eclipse Plugins

November 5, 2008 Leave a comment

image Tech leads are continually challenged with identifying and governing code quality. The common response is to look to test coverage as a measure of quality. Previously I was challenged to monitor code and architectural quality for over 50 developers both on and offshore. The shear amount of code made manual reviews a nightmare. While had reports on coverage it became apparent that the quality of the tests themselves  was also in question. It was time for a more automated review of quality.

After reviewing a series of tools and working through various industry best practices, here is the list of tools I ended up relying on regularly.

Automatically Format on Save

The standard fare

Often Overlooked

Code Coverage

Focus on the important code

There are a few really good articles to help you get up and running with these

Check out:

Andrew Glover: In Pursuit of code quality

Metrics

Use the tools available to analyze faster and make your code stronger.

FEEDBACK: Let me know if there are other tools or resources that make your life easier.

Bite Size: Refactoring in Eclipse

August 6, 2008 Leave a comment

IDEs offer many tools that speed up the development process. Among the many features in eclipse for coding are a series of commands for refactoring code. Understanding how to quickly utilize these commands will dramatically speed up your development process.

  • Display Available Refactor Commands (Alt+Shift+T)
  • Rename (Alt+Shift+R)
  • Extract to Local Variable (Alt+Shift+L)
  • Extract to Method (Alt+Shift+M)
  • Change Method Signature (Alt+Shift+Y)
  • Undo Refactoring (Ctrl+Z)