Software Architecture: Disciplines, Practices, and Principles

Original link: http://www.linkedin.com/pulse/software-architecture-disciplines-practices-brian-buikema

 

Overview

Inspired by my experiences watching startups that grow up into viable businesses, I’ve witnessed how most parts of a company experience growing pains.  And the IT department is no exception, and in fact, can struggle to accommodate the business the most.  Especially as stakeholders want to accelerate the development of more products and features to penetrate and capture as much of the market as possible.  Strike while the iron is hot, right?

The problems I’ve encountered in fast growing, high-tech startups are understandable by techies, but harder to understand by business folks.  For example, high-tech businesses commonly get kicked off from proof-of-concept software developed specifically to convey and prove a product vision. Establishing a well-defined software architecture that scales with the business as it grows exponentially and signs gazillions of users, is usually not on the forefront of folks minds in the very early start-up stages.  Getting something to demo to potential customers asap and helping launch the business is paramount at this point.

Fast forward to the Software Development team of a business that successfully made it out of the startup stage, and is being asked to develop products and features faster, with higher quality, and 99.9999% up time. Since the current product offering was developed by different folks/teams throughout the start-up times, often in parallel without a clear architectural vision, the software architecture “as is” now hinders the business with performance bottlenecks, lengthy development cycles, inability to support business intelligence and enterprise reporting initiatives, etc…

That Software Development team needs to take back control of the Software Architecture, capture and understand the current state architecture, identify the architectural assets and liabilities, and establish a strategy and plan to create a future state architecture, in order to move the company forward.

Take Back Control of Your Architecture – Task List

Focusing on improving your software architecture can be a bit daunting.  You may not find suitable articles and education to adequately prepare you.  From my experiences, especially maturing startups, I’ve identified the following task list that take back control of your Software Architecture.  This task list is a good starting blueprint, and can be customized to fit your needs.  Keep in mind that it takes great commitment and disciplineto develop, adopt, AND ultimately move forward with this.  But it will yield great results for the entire organization.

  1. Define the Mission Statement
  2. Identify Goals, Considerations, and Deliverables
  3. State the Key Architecture Principles
  4. State the Key Design Principles
  5. Capture the Current State Architecture
  6. Identify Business Gaps in the Current State Architecture
  7. Identify Technical Gaps in the Current State Architecture
  8. Identify the Assets and Liabilities of the Current State Architecture
  9. Identify All Quality Attributes that need to be Supported by the Software Architecture
  10. Identify the Business Needs for the today and the next 6, 12, 24 months, and Beyond
  11. Balance Stakeholder Needs
  12. Moving Forward – Create a Strategy, Plan, and Milestones and Build a Future State Architecture
  13. Solving the Business Gaps in the Current State Architecture
  14. Solving the Technical Gaps in the Current State Architecture
  15. Educate the Team on all Strategies, Plans, Principles, and Milestones
  16. Broadcast this Important Achievement to the Business to Instill Confidence back into Software Development

Next we’ll discuss these tasks in detail.

Take Back Control of Your Architecture - Task List Details

Let’s get right into it.

Define the Mission Statement

Simply put

What do you want to accomplish?  Who do you want to satisfy?

Do not discuss detailed goals and deliverables.  Just your mission.

Identify Goals, Considerations, and Deliverables

This is where to discuss the goals, considerations, and deliverables of your mission.  But do not get caught up in the how.  Just the goals, considerations, and deliverables and nothing more.  Bullet points and small paragraphs are fine.

State the Key Architecture Principles

Principles give strong guidance.  Regarding key architecture principles, I provide the following I use:

  1. Build to change instead of building to last
  2. Model to analyze and reduce risk
  3. Use models and visualizations as a communication and collaboration tool
  4. Identify key engineering decisions
  5. Key considerations
    1. Design Practices
      • Keep design patterns consistent within each layer
      • Do not duplicate functionality within an application
      • Prefer composition to inheritance
      • Establish a coding style and naming convention for development
      • Maintain system quality using automated QA techniques during development
      • Consider the operation of your application
    2. Application Layers
      • Separate the areas of concern
      • Be explicit about how layers communicate with each other
      • Use abstraction to implement loose coupling between layers
      • Do not mix different types of components in the same logical layer
      • Keep the data format consistent within a layer or component
    3. Components, Modules, and Functions
      • A component or an object should not rely on internal details of other components or objects
      • Do not overload the functionality of a component
      • Understand how components will communicate with each other
      • Keep crosscutting code abstracted from the application business logic as far as possible
      • Define a clear contract for components

State the Key Design Principles

Regarding key design principles, again I provide the following I use:

  1. Separation of concerns
  2. Single Responsibility principle
  3. Principle of Least Knowledge (also known as the Law of Demeter or LoD)
  4. Don’t repeat yourself (DRY)
  5. Minimize upfront design
  6. Key considerations
    • Determine Application Type
    • Determine Deployment Strategy
    • Determine the Appropriate Technologies
    • Determine the Quality Attributes
    • Determine the Crosscutting Concerns

Capture Current State Architecture

It is important to capture current state architecture, especially if one does not exist or is out-of-date.  At a minimum, think solutions architecture.  That is, capture the

  • Logical Architecture
  • Physical Architecture
  • Information Architecture
  • Security Architecture
  • Integration Architecture
  • and any known NFR’s (non-functional requirements), i.e., observable qualities such as system performance, availability, dependability, etc…

And most important.  Be honest and don’t leave any important details out.  You may be responsible for parts of the architecture, and are even a bit embarrassed, but

now is the time to mature the software architecture to match the growth and maturation needs of your organization.  Also, pat yourself on the back as the current state architecture launched a successful business.  Good job!

Identify Business Gaps in the Current State Architecture

If you don’t know any, I bet your business folks do.  These are usually shortcomings in the architecture that affect your team’s ability to develop user features and even full products.  It is useful to comb through known issues and dive a bit deeper to understand the underlying issues.  Examples are:

  • page loads are too slow
  • have to log on more than once within the app
  • need insightful reports
  • need API’s
  • need faster feature development
  • missing core feature(s)

Identify Technical Gaps in the Current State Architecture

This is usually easy to identify.  Examples are:

  • we don’t support SSO
  • we can’t scale our data store
  • we don’t support data analytics and OLAP
  • we don’t have a data warehouse
  • we’re too tightly-coupled
  • the application is monolithic
  • we don’t support API management

Identify the Assets and Liabilities of the Current State Architecture 

Again, be honest and don’t leave any important details out.

Assets can be

  • architecture is distributed and scaleable
  • is service-oriented and multi-tiered
  • good data model(s)
  • extensible frameworks
  • extensible designs
  • good selection and integration of technologies/platforms
  • smart incorporation of architectural patterns
  • smart incorporation of design patterns
  • loosely coupled components
  • business logic well-contained within the business layer
  • …

Liabilities can be

  • architecture is not a distributed or scaleable
  • not service-oriented, e.g., two-tiered client-server
  • bad data model(s)
  • non-extensible frameworks
  • non-extensible designs
  • bad selection or integration of technologies/platforms
  • poor incorporation of architectural patterns
  • poor incorporation of design patterns
  • tightly coupled components
  • business logic scattered amongst many layers
  • …

You get the picture.

Identify All Quality Attributes that need to be Supported by the Software Architecture

At the high-level, think

  • Quality Assurance
  • Release Planning
  • Deployment and
  • Maintenance

Details include instrumentation and logging, straight-forward support for CI, automated testing, providing the right sized QA staff, tools for Sysops, etc…

Identify the Business Needs for Today, the next 6, 12, and 24 Months, and Beyond

Collaborate with your business leaders to determine key milestones targeted by your organization.  Use this information to help plan out the needs of your Software Architecture.  Of course, you should always be thinking and planning extensibility at all levels of the architecture, right?!!!

Balance Stakeholder Needs

I add this task as it is important to remember that software development, and in particular, software architecture, can take some serious time.  The business will be patient to a point.  Is it six weeks, eight weeks, a quarter?

Ultimately, the business must have concrete features and products being developed and delivered in a timely manner in order to move the business forward.  A balance must be found between architecture, infrastructure, and delivering features and products.  This requires experience, and the more senior folks should be better equipped to help plan this.

Moving Forward – Create a Strategy, Plan, and Milestones and Build a Future State Architecture

The results of the above tasks should provide enough information to begin strategizing and building the future state architecture.  Pay special attention to the business and technical gaps stated earlier.

Like the current state architecture, develop the future state architecture’s

  • Logical Architecture
  • Physical Architecture
  • Information Architecture
  • Security Architecture
  • Integration Architecture
  • and any known NFR’s (non-functional requirements), i.e., observable qualities such as system performance, availability, dependability, etc…

Lay out the applicable architectural style and patterns, current assets, and new technologies to explore.  How will the current liabilities be addressed?  How will the future business needs be addressed?  Will proof-of-concepts need to be developed to identify those technologies to adopt and mitigate risk?  How long will they take to develop?

Will the software development team need to be trained on new technologies, how long will that take, and when will they be proficient developing using the new technologies?

Can reasonable milestones be achieved?

Do not delay creating a plan, and remember that agile organizations move forward with incremental deliverables and successes.  Build on that, and visit your progress frequently.  And never be afraid to quickly make the appropriate changes to course correct.

Solving the Business Gaps in the Current State Architecture

For each gap, it is important to identify how the future state architecture solves it.  Examples are:

  • use caching
  • install an Identity Server and refactor authentication
  • install an OLAP Server and data analytical platform/tools, then develop insightful reports
  • install an API Management Server, craft API development strategy, and develop and release API’s
  • …

Solving the Technical Gaps in the Current State Architecture

Again, tackle how the future state architecture solves each gap.  Note:  You may notice that the business and technical gaps are very similar, if not the same, and their solutions are therefore largely the same.  Examples are:

  • use caching
  • install an Identity Server and refactor authentication
  • install an OLAP Server and data analytical platform/tools, then develop insightful reports
  • install an API Management Server, craft API development strategy, and develop and release API’s
  • refactor monolithic application into RESTful services
  • …

Educate the Team on all Strategies, Plans, Principles, and Milestones

Group your folks up and enlighten and educate them on the new plans for software architecture.

My recommendation is to keep it fun and focused.  Maybe have pizzas delivered for lunch, and present the future strategies, plans, principles, and milestones of your software architecture.  Keep it high-level to keep it moving, delving into details when necessary.  Provide all details in diagrams and documents that can be referenced anytime.

Broadcast this Important Achievement to the Business to Instill Confidence back into Software Development

As the business puts more pressure on software development, the early software architecture gets exposed, as it was designed to prove business concepts and, ultimately, launch a company.  It was not architected to support a gazillion users, and delivering x number of products and y features per quarter.

But now you can.  And it’s time to brag about the new direction of software architecture to the business.  Just keep the boring technical details to a minimum, and highlight the benefits to the business!

Thanks for reading and please stay tuned as I have many insightful subject matters to share with you.

posted @ 2017-01-17 23:05  southdom  阅读(192)  评论(0)  编辑  收藏  举报