1. SDS Architecture A prototype for the future Shawn Weekly Southern Company sweekly@southernco.com

2. Abstract Who am I/Who are we Who is this topic for What problem are we addressing What are the goals of this discussion

3. Problem Definition What’s the scope of our work? Smaller, more manageable chunks Answer these questions Given our answers, we define ourselves as a “large, complex” environmentour answers

4. Our environment 4 operating companies in play @ 2 geographical locations w/~6720 Facilities (Substations or Lines) P&C, Physical, and Civil/Structural disciplines Integration with 3 custom systems (Estimating, Material Handling, Document Management) ~325 CAD users, about 2500 drawing viewers/users Close to 1 million active CAD drawings

5. Our plan Step 1: Standardize Step 2: Identify Risks Step 3: Mitigate the risks Step 4: Create an architecture

6. Step 1 Standardize design processes across discipline & OPCO design and support tools across discipline & OPCO parts libraries in the P&C and Physical discipline across OPCOs part identifiers across OPCOs

7. Standardization “Shrinks the target” reduces scope of the technical effort Highlights opportunities for improvement Is absolutely critical to do this work properly!

8. Step 2 Identify risks Some states will dictate different design standards, especially in Civil Some OPCOs require different parts Different OPCOs use the tools differently Different OPCOs identify the same part with a different Material ID

9. Risk ID Understand that you will have risk – plan for it Find things that will require more effort Mitigate while you have the time and money to mitigate

10. Step 3 Mitigate with process or tools Find the pain points and fix them Common processes might cost less than tools If tools, Less is More Present information, not data Limit decision points Plan for maintainability and future needs

11. Our ‘pain points’ Too many tools Each OPCO with their own version or process A lot of data entry No synchronization Lots of tacit knowledge required Legacy, hard to maintain systems

12. Step 4 Architecture Reduce the number of tools used DRY (Don’t Repeat Yourself) If the data lives elsewhere, call for it Loose coupling Don’t push data to systems of record, let them pull it

13. Overview Staging Area Data and files for push/pull ops Vendor responsibilities SDSS component using Vault/Automation force APIs Vendor only needs to know staging schema SCS responsibilities Systems of record pull data on internal schedules Duplicated features (DMS) abstracted away and eventually replaced with Vault

14. Visual Overview

15. Retire DMS system Abstract existing DMS system features to ‘hide’ both it and Vault Reduce feature shock/loss of function Decouple process from system Phase out old, phase in new, rebuild missing features on modern platform

16. Visual retirement

17. Environments 4 environments Self Contained/Stand Alone/Virtual Development Training Production NAS based file share SQL Server on own machine Vault on own machine UAT (User Acceptance Testing) Identical to prod but separate hardware

18. Visual Overview

19. Tech. Details Staging Area SQL Server w/redundancy NAS devices with snapshots and replication across WAN Components.NET web services, WCF and/or RESTful services HTML5 based UI so it can be used on desktop in CAD tools and mobile and web Redundant application servers

20. Expected Results Simplified maintenance Modern tools and language w/ large pool of knowledge Less tacit knowledge required Disaster planning Reduced impact due to change upstream Streamlined toolbox for users More efficiency, less training

21. Summary Review of our plan Standardize to reduce scope Risk assessment Mitigate early to save cost More process/less tooling What can I do now to save time/money later? Don’t forget testing/training and DR! Make a plan for you!

22. Questions ?