Learn how to review IT architecture.
- What an IT architecture review is
- How to do an IT architecture review
- Lots more
So if you want to know all about IT architecture review, then this article is for you.
Let’s jump right in!
IT Architecture Review 101
An IT architecture review is perhaps the most critical step in keeping your company’s valuable data safe from malicious entities.
Understanding what IT architecture is and how to review your setup is pivotal, not only to keep your business running smoothly but also to remain in compliance as you store your customer’s data.
This kind of project involves asking your client several questions and checking every nook and cranny of their IT infrastructure.
Knowing what to look for is critical. Knowing how to translate what you’re doing so your client understands is equally essential.
Simple Overview of an IT Architecture Review
Think of IT Architecture similarly to how you might view your house. Your number one priority might be to keep bad guys out.
On top of that, however, you want to ensure you have easy access and a smooth flow as you walk room to room. In other words, the layout needs to make sense.
It might help you first to see the difference between what a bad IT architecture setup looks like compared to the best layout.
Here’s a fairly entertaining video of two guys laying down the truth about it:
Bad IT Architecture Setup
When performing a system architecture review, you don’t want to see this kind of setup.
The most glaring flaw in its layout will be the absence of a firewall.
Internet feeds into the ISP router and then directly into the internal infrastructure. This is bad.
Even worse, malicious entities can gain access to your data and operations if they manage to get in through your external web server.
With no firewall in place, everything is wide open. It’s like leaving every door in your house unlocked.
Good IT Architecture Setup
Whereas a bad IT architecture setup is disorganized and basically a plan with no direction, a good design takes all the same elements and brings order and security.
Internet feeds in through an edge router and immediately hits a firewall. This may surprise you, but that is the most critical difference between a good and bad IT architecture setup.
By utilizing a firewall, traffic is directed immediately into what we’ll call the red zone.
The red zone contains access to your external web server and your database server, and an ACL sits in the middle of this zone as the traffic officer, allowing or denying every outside entity attempting to access your data.
Although your database server sits in the same zone as the external web server, the ACL prevents access to your database from the other. For denied traffic, the journey stops there.
Approved traffic is allowed to pass through the database and back through the firewall, then into your internal infrastructures, such as PCs, printers, files, and other servers.
What is an IT Architecture Review?
With that simple overview under your belt, now let’s dive into the specifics. You want to go ground level with the intention to provide efficiency and security.
An IT architecture review studies your network’s design structure, aims to fix flaws, and targets areas for cost-effective optimization. This is where the architect picks up the blueprint and compares it to the house in progress.
You may not want to read this, but the house requires constant maintenance.
There are routine tasks to perform, technology to identify and standardize, and resources to consolidate and centralize.
The IT architecture review is about optimizing every aspect of the network.
IT architecture itself encompasses a system’s organization, the components comprising that system and how they work together, and the rules set to guide the system’s design and growth.
Knowing the goal prioritizes the steps in your IT architecture review process, and the primary outcome is to ensure compliance.
What is IT Architecture Compliance?
Compliance concerning IT architecture means two things: one, you’re implementing best practices to ensure the desired outcome and to avoid future roadblocks; two, you are ensuring the IT architecture conforms to industry standards and aligns with your business’s objectives.
A thorough IT architecture review checklist appears later in this article, so feel free to take it and customize it to meet your needs.
Not all projects are the same, so the tasks you undertake should be relevant to you or your client’s desired outcome.
Whether you are an IT architect or planning to hire one, it’s essential to understand the language and required tasks to meet your goals.
The IT Architecture Review Board
The IT Architecture Review Board monitors your system’s design for consistency, effectiveness, and compliance.
Your IT Architecture Review Board process’s scope depends on your business’s size, system setup, and goals. Here’s a brief overview of a standard review board.
The IT architecture review request is submitted. An IT architect is assigned the duty of determining the scope of review for the organization.
Checklists are tailored by the architect to address all areas of concern. The architect and review coordinator then meet so they can get on the same page.
From there, interviewed project principles maximize understanding of processes already in place. Their input provides suggestions to optimize those processes and move forward.
The IT architect then conducts a further review to ensure compliance with the standards in place, resolve issues, and determine additional recommendations.
The last step in this process sees the architect present his or her IT architecture review report to the customer or IT architecture review board.
A Deeper Look Into the IT Architecture Review Board
Now that you know what steps are needed for the review board to function let’s take a look at the specific roles of those involved. This is less a chain of command and more of a machine coming together to form the whole.
- Project Leader: Claims responsibility for the entire operation.
- Architecture Review Coordinator: Administers development of IT architecture and its review process. This role usually fixates on the business side rather than technology.
- Chief Architect: An IT architecture specialist who ensures technical coherence.
- Architect: Assists the Chief Architect.
- Customer: Represents the business and its system under review. The customer communicates business requirements and goals.
- Business Domain Expert: Might be the same as the customer. Understands the business’s processes and ensures clarity on them throughout the board.
- Project Principles: These are members of the customer’s business who provide input on requirements to meet. Their role is to maximize understanding across the board.
Create an IT Architecture Review Board Charter
It may also help to write down an IT Architecture Review Board Charter. An effective charter should clearly outline your review board’s:
- Reporting requirements
- Method of Operation
- Quorum details
- Decision-making guidelines
- Secretarial responsibilities
Use this IT architecture review board checklist to craft your own and increase the effectiveness of your organization. You can review an example charter here.
Goals of the IT Architecture Review Board
The Architecture Review Board develops strategies appropriate to customer definitions.
The board ensures system development aligns with the customer’s desired outcome. It also implements design standards, policies, and principles for the entire IT infrastructure.
The Architecture Review Board’s mission is to improve IT and IS quality.
By implementing best practices, the board establishes a roadmap to success and leads the review process.
New technologies are identified for the customer to replace older, inefficient technologies bogging down the system if necessary.
Should the customer reject recommendations, the review board must redirect their efforts into devising new strategies.
The review board considers all input from board members to form efficient and cost-effective solutions for the customer.
It is equally important to consider feedback and consultation with company stakeholders and include them in the software architecture review and assessment report.
The IT Architect
Whether you employ one or a team, it is vital to understand the IT Architect’s job functions and what those functions do not encompass.
IT architects are not responsible for:
- Hardware specifications
- Software specifications
- Requirement gathering
The IT architect may make recommendations to that effect, but the architect’s real purpose is much broader. Here is what the IT architect is responsible for:
- Planning direction and standards for recommended technology to support
- Architecture plan, design, and purchase review
- Opportunity identification, such as determining services and components to recycle
- Business organization and process review
An IT architect can determine how well the course decided on aligns with the customer’s desired outcome.
The architect hunts down inefficiencies within the system’s framework to make cost-effective recommendations, such as integrating shared services.
Benefits of an IT Architecture Review
There are myriad benefits to an IT architecture review, such as:
- New communication channels opened with stakeholders
- Improved architecture and design quality
- Identification of non-functional requirements
- Creation of a roadmap to implement proposed architecture
- Delegating system design responsibilities
- Resolutions for conflicting requirements
- Critical error identification to prevent future catastrophes
- Cost reduction through those error identifications
- Best design and evaluation practice implementation
- Identification of opportunities to recycle components
And there are many more benefits to an IT architecture review. An IT architect ensures that the system in development aligns with your goals and provides recommendations to improve functionality and performance.
The assessment helps bridge gaps to build a solid framework for the customer.
What the IT Architecture Review Looks for
Here’s the truth: when it comes to IT architecture review, you can always get more specific.
The review’s general purpose is to hone in and identify everything.
Laser-focused scrutinization leads to the best considerations and recommendations for improvement.
The intended outcome of the review, not just in terms of the client’s specific expectations, is to manufacture coherence within the architecture.
Coherence is the backbone of flow and efficiency. This means cost-effectiveness for stakeholders and success for the customer.
An IT architecture review assesses the system’s logical requirements, such as:
- Modularization: the degree to which a system’s components can be separated and combined.
- Information Hiding: segregation of design decisions within a computer program that are most likely to change.
- Abstraction: the generalization or process of removing unnecessary details or attributes to focus attention on details of greater importance.
- Encapsulation: the bundling of data with methods that operate on that data or restrict direct access to specific components.
The IT architect reviews the system’s process, items which can be measured, such as:
- Flexibility: also referred to as adaptability.
- Security: protective measures against possible breaches
- Scalability: the ability of a system to meet increased workloads
- Performance: how efficient a system’s processes work
- Reliability: how consistent a system performs
- Availability: defining the components of a system for optimal performance
- Maintainability: how well a system can support changes
In addition to logical requirements and system processes, the IT architect also reviews the physical infrastructure and its components.
Planning the IT Architecture Review
At the outset of your review, you must clearly define the desired outcome and determine what will be delivered to the customer.
Ask the customer what they want and how will the information you provide be utilized. Knowing your customer’s target gives you a target.
The IT architect does not implement or perform any potential changes. The architect only gives recommendations based on the review.
An architect compiles a detailed report of recommendations regarding system flaws, shortcomings, and cost-saving fixes, then hands the report to the team responsible for administering those changes.
The IT Architecture Review Purpose
As you hone in on why the review is necessary, let’s review some key aspects of the architect’s many tasks.
The primary purpose of the review is to weed out errors before they cause catastrophic failures. Better to patch a hole before the pool leaks empty.
By catching errors and flaws early, you help reduce a project’s cost and risk. Overall project time is shortened with these issues already addressed, and development progresses smoothly.
Throughout your review, be sure to implement best practices and thorough evaluations.
Some standards may require modification. Some services may perform more efficiently if integrated elsewhere.
As you conduct your review, be sure to document everything and make notes for where better technology may be applicable.
Throughout the review, you may also find architectural alternatives that may serve the customer even better.
Architects take a deep dive into a business’s technical infrastructure and its systems, which is an area the customer likely knows little about.
That’s why the review must be comprehensive and address the most critical risks found.
IT Architecture Review Checklist
When you perform an IT architecture review, the first things to keep in mind are the basic system engineering disciplines, such as information and security management.
Treat the following checklist as an IT architect review template from which you can customize and craft your own.
Systems Engineering—Methods and Tools
- Are there metrics for current business processes?
- Do current evaluation criteria exist to guide the review?
- Implement unique project methods. You’ll need to define the following:
- Business strategies
- Areas needing improvement
- Current business processes and processes that will potentially replace them
- How that transition process will occur
- Project management
- Team communication channels
- Software development
- Referencing standards
- Quality assurance
- Metric documentation
- Are there current processes in place to ensure compliance?
- Outline consultation and troubleshooting methods
- What tools will be used? Will training for these tools be required?
- How can components be reused within the project?
- Do other systems require integration with the project?
- How is the user base geographically distributed?
- What is the size of the user base?
- How will other user communities inside or outside the organization utilize the system?
- What assets are needed to provide service?
- How will non-native users access data within the system?
- How does the design accommodate the customer’s needs?
- What software and hardware are utilized currently, and what additional resources will be needed?
- What is the current configuration of the system’s setup?
- What is the current maintenance cost versus the system’s projected maintenance cost after reviewing and implementing recommendations?
- What tools facilitate software distribution?
- What is the frequency of required software changes?
- Will production all multiple software and applications?
- How often is user data backed up? How quickly can it be restored?
- Determine how user accounts are created and managed
- Determine a strategy for system license management
- Determine tools needed for general system administration
- Define the procedure for receiving and responding to service calls
- Define the process for uninstalling within the system and for the system itself
- Does the system have the capability of reporting its own error messages?
- Determine policies and guidelines for security awareness, current and needed
- Determine how users will be identified and authenticated within the system
- Map the process for how users access the system, how requests are approved, and how appropriate access levels are recognized
- Determine the governance and maintenance of user ids and passwords
- Develop a strategy for distributing security information to users, such as compliance standards, access agreement, and their responsibilities
- Determine how sensitive data is identified and protected
- Develop a strategy for audit logs and tracking
- Determine if the system can be accessed externally—if so, what protections will be put in place to protect valuable data?
- Regarding Data Values
- What processes standardize and manage data use?
- What process governs data entry, validation, and use?
- What process governs data deletion?
- Regarding Data Definition
- Determine data model, definitions, structure, and hosting options
- How is data shared and supported within the system?
- Determine tools for software development and data management
- Determine data owners and their responsibilities
What capabilities does the system require? Consider the following:
- Business acquisition processes, such as sales and marketing
- Engineering applications needed for statistical analysis
- Supplier management applications for supply chain management and customer relationships (CRM)
- Manufacturing applications for resource planning, strategy execution, and quality assurance processes
- Customer support applications
- Information Systems (IS) applications needed for software and web development
- How will the system administer application integrations?
- Determine how methods are defined and arranged within applications
- Determine how errors are defined and addressed
- Define the process for handling service calls to address and correct errors
- Determine communication protocols between components
- Determine methods for object creation, use, and destruction
- Determine methods for recycling objects if destruction can be avoided
- Outline the code review process
- Outline system testing methods
- Determine if and how well components within the system are compatible with the interface
- Determine time and date functions for compliance
- Determine tools and processes for guarding against memory leaks and other errors
- Define the communication process between applications within the system
Hardware Service and Operation
- Project the life cycle of system operations and the system’s overall life expectancy
- What is the current stage of the system’s life cycle?
- Determine critical issues to analyze through evaluation of the network, servers, and end-user devices
- How does the system currently handle high volume and frequent data transfers? What recommendations can be made for improvement?
- Determine the quantity and distribution of data usage, storage, and processing, on both a regional and global scale
- Address non-standard hardware choices and how they are, if they can be, justified
- Determine the process for cost-evaluation of hardware and operating systems, both current and lifetime
Remember, this checklist may serve you as an IT architecture review template.
You will likely encounter unique issues within each project which require unique approaches and process development.
Disregard what you find irrelevant to you here and utilize the rest, tailoring it to your project’s specific needs.
Guidelines for IT Architecture Review
When you embark on a new project, standardize your focus for coherence through the project.
Address high-risk areas and expected differentiators within the system. Forecast issues that may arise so that they can be addressed ahead of malfunction.
Consult regularly with the IT Architecture Review Board, the customer, primary principles, and stakeholders to ground progress and goals.
Tailor the checklists you develop as needed throughout the process to suit emergent needs.
Listen to feedback, implement, and resume communication for more.
Strive for clarification in the objectives presented by the customer.
Understanding their goals will guide your process. Consider what they want in simple terms and translate your review to meet their comprehension.
Basically, the customer wants to know what works and what doesn’t, what’s efficient and what isn’t. Provide only relevant information in the review concerning the objectives laid out.
Should you find additional recommendations that are needed but perhaps don’t fall within the request’s scope, offer those recommendations as an aside.
After Review Guidelines
Should it become apparent that other issues need to be addressed throughout the review and final discussion, make a plan and present it to the customer.
Determine if the problem really falls outside the scope of the initial request, and if so, determine its level of urgency.
Although the language used should make sense to the customer, there is no need to “dumb it down.” State things simply, but don’t shy away from using industry terms.
Remember, the architect’s job is to make recommendations, not to force preferences.
Developing Your Own IT Architecture Review Interview
While you may have your own checklist full of technical jargon to steadily guide you, consider the specifics of your interview with the customer for their needs. Namely, the questions you will ask them.
Be sure to ask open-ended questions that do not presume particular answers and do not guide a response.
Should you uncover controversial issues through the discussion, remain depersonalized and professional.
As your job is to aid the customer, treat the review as a learning experience both for yourself and those you’re helping.
The system currently in place may not be built perfectly, but that’s why you have been called in.
Make the appropriate recommendations and then leave it in the customer’s hands.
Commonalities Between IT Architecture Reviews
While you will always find unique issues to be addressed within each review, each system requires common tasks.
You might treat these as jumping-off points to get each review started.
Keep this short checklist handy to hold your review together, like the spine of a book.
- Eliminate information resource silos by consolidating as many features as possible.
- Determine data requirements, how data is used, and where it’s stored—and determine the compliance of data usage with business requirements
- Identify resources that can be integrated with the new system, resources that can’t, and if alternative resources are prudent
- Define standards, rules, and guidelines for the customer to follow in system operation and management
- Justify your recommendations within your review—communicate the value the changes you suggest will bring
What the Review Should Improve
The following is what your thorough investigation should improve for the customer:
- Technology resources, especially regarding data management
- Resource use, recovery, security, and service
- IT personnel management, in particular, the skills needed to maintain the architecture
- Redundancy, particularly regarding hardware with identical functions
- File storage centralization
- Ease of use regarding directory services, such as log-ins, passwords, and authentication
System Maintenance and Automation
Determine the process for system upkeep. How will patches and updates be administered?
What virus protection will be put in place?
These types of maintenance and safeguards must be updated regularly, the entire system will require routine scans to ensure compliance and security.