Greetings. I am John Conley III, your humble technology servant and owner of Samsona Software Inc., which I founded and incorporated back in 1993, when the internet began to take off. I am ready at your disposal to help you articulate your vision from conception all the way through delivery in the form of a desktop app, web app or mobile app, or even a behind the scenes software solution such as a web service (including microservice) or data access/system integration tool. Whatever you can dream up, we can software it in a controlled, methodic way.
Over the recent years, I have usually worn the hat of Software Product Planner, Enterprise Architect, Solution Architect, Project Coach or Sr. Application Architect. My common tasks include helping executive stakeholders and project managers plan the software product from the vision, preparing a solution architect design document (SAD) that bridges the gap between the vision or high level requirements of the desired software product/solution to the technical development and deployment of the solution, and driving the downstream technical partners to deliver the software incrementally per Agile sprint. I advise or manage the technical expectations of PMs and Scrum masters, as well as participate in software product planning sessions with marketing executives…System integrations (service bus, message queues, etc) and design pattern advisories are often involved. The requirements usually range from Agile stories and epics to use cases and traditional BRD waterfall requirements, and often involve identifying business processes captured using TOGAF-based BPM diagramming tools or even plain Visio. The SAD document typically follows a template which, in a nutshell, describes the current and target state of the solution from a technical view. With this approach, every complex business problem can be solved methodically. Solving complex business and technical problems comes natural.
The SAD would contain a component context diagram for the current state and target state to show high level components with interfaces linking them. Each interface will have end points, and each end point must have an agreed messaging protocol for communicating. For a services-based SOA architecture, these end points are sometimes (but not necessarily) SOAP or JSON based where one is the Sender and the other is the Receiver. I often point out the SOAP version that each service end point supports to help in deciding which component could also support the necessary SOAP version or whatever messaging protocol is required. Behind a secure firewall, classic API communications can also be designed and deployed. Authentication and authorization solutions would incorporate Active Directory or OAuth (Visual Studio 2015/C#). Specifying this level of point-to-point interface detail for orchestrations involving several major components spanning multiple lines of business can be quite helpful in providing a technical context for technical teams to do their thing, whether it be waterfall, agile, or a combination of both.
Need help prepping for a sales pitch? Our offering is pretty much similar to the description above, except a lot more involvement with product planning and customer presentation preps, focus group follow ups, elaborating the vision statement for the customer, creating end to end POCs with mock data in any relational DB and shall services (monolithic and microservices) to show end to end functionality for customer demos, provide technical feedback to developers to enhance products for customers, etc.
More Agile projects may limit the depth and coverage of the SAD, but at a minimum, there would be a roadmap for applying enterprise and solution best practices and governance, including security, corporate standards, and any legal or regulatory compliance items.
The SAD docs would also include a section justifying the target state solution which sometimes incorporates what’s called an Architecture Alternatives Analysis (AA) matrix, aka spreadsheet. This matrix will compare two or more candidate solutions, and compare them feature by feature with each row assigning a weighted score from 1-10 where 10 implies this solution meets or exceeds the needs of this feature perfectly. A priority can also be assigned to each row to highlight which features are more mission critical than others. This exercise is helpful when comparing, say, a solution from IBM vs Oracle, or Microsoft vs Salesforce, for instance.
If any of this technical jargon is of use to you, perhaps we can get started with one of your project visions today, or at least help an existing project get beyond a design or development rut before it’s too late! Contact us today!