Project Scope

Before any project is started, we need to define the scope of the project. Success is dependent on how well we manage the scope. To help with this, you need to create a logical view showing the scope of the project. Key to managing the scope is knowing the business processes and data aspects of the proposed solution.

In Steven Spewak’s book, Enterprise Architecture Planning, he describes the four pillars of Architecture. The pillars are Business Process, Business Data, Business Solution and Technical Architecture. The project initiation stage only requires an understanding of three of the four. Technology is not needed in the beginning.

Enterprise Architecture

A decision about technology should be made after understanding your solution logically. A logical view is used to determine the best technology. A simple example is what DBMS to use. If you are interested in Market Research, you might choose a NoSQL DBMS for your solution. Data loaded from multiple sources is used by your data scientist to search for leads. Contrast that with customers registering with your company. In that case, a relational DBMS may be the best choice. Your technology choice should be saved until you understand the business need.

Technology is chosen the business need is understood. Business, Data and Solution remain and are used to create a logical view of our business. In Spewak’s book, a solution is defined as the affinity between process and data. When data is created by a process there is a high affinity while if data is read by a process it has low affinity. To start, we need a solid understand of the Process and Data. Using affinity analysis, we can determine how to organize the solution.

While, Enterprise Architecture is a scary term and some people think of it as boiling the ocean. The approach is a sound way to organize and understand your solution. Taking the approach of understanding the business process and data provides you with a view of the ocean.

‘Enterprise’, what does that actually mean? We have all heard ‘big E’ or ‘Little e’ when referring to Enterprise architecture. What does ‘big E’ versus Little e’ tell us? It is really defining context. Context is analogous to scope. So while this approach is from an Enterprise planning book, use it as an approach for the problem you are trying to solve.

Be creative, do not be afraid to use this approach on a small project. Understand the processes you are trying to automate or improve and get an understanding of the data. Once you have a logical understanding, you can then go into the details to define your requirements. The detail data requirements, user interface, data services and DBMS layer. Then you can look in your tool chest of technology and apply the correct one to your project and be confident if what you build.

Check out this page which describes why context is important. Well-defined context creates an immutable property or boundary that software developers can follow.