Posts

Showing posts from June, 2022

Non Functional Requirements - NFRs - in Software Systems

Image
NFRs are requirements that do not relate to business functionality. They relate to attributes like reliability, efficiency, and portability. Non Functional Requirements are architecturally significant requirements because they impact the system architecture. They are properties of a system that sit outside of specific business features or functionality. NFRs are sometimes called constraints. Other times they are called Quality Attributes. Constraints generally change the shape of architecture or design. Capturing NFRs early is part of a shift left where we surface the non-business value needs earlier in the process. Non-functional requirements impact the system as a whole and are cross-cutting across business features. when the non-functional requirements are done well, you may eliminate 50 to 80 percent of product defects.   Credit: Jamsoft Project efforts really need to be explicit about capturing their NFRs and updating them. Everyone has been on projects where some technical requi

Event the heck out of it so that you can drive insights and and keep options open

Image
Business and Technical events are an early, easy, way to capture activity, notify other systems of activity, capture technical changes, and log executed business functions. The information needed for those events tends to reside in specific steps in an execution flow. This means we often need to insert event generation probes in multiple places and at multiple levels. Product owners need visibility into any business functions or services that are performed.  Technical teams need visibility into the detailed activities executed in a system.  Partner business functions and data stores need a way to reconstruct the data as it existed at a specific times Databases often only provide a current or point-in-time state.  Logs have PII restrictions. Metrics are statistical by their nature. 

Urban Dictionary - training wheels for inclusion?

Slang and culture dictionaries can help us understand others without forcing them to completely code switch for all our interactions.  We don't want to remove bans on insulting or demeaning speech.  We do want to let people use their native phrasing and nuance and find the tools that bring us to their world.   The Urban Dictionary and others have a bunch of terms that don't belong in the workplace.  They also have a lot in them that pushes some of us at least one step closer to the sphere of others. Consider inclusion separately from diversity.   Research shows  that valuing diversity is not enough to reduce discrimination toward minorities. In addition to focusing on diversity, organizations need to  create inclusive environments  for employees to feel comfortable bringing their authentic selves to work.  "The Cost of Code-Switching" Harvard Business Review.     

Management by Impossible Objective

Image
Management by Impossible Objective  is a style based on the idea that people will produce more in less time if they are given goals that are difficult to achieve.  It often morphs into goals that are impossible to achieve based on the notion that the only way to max out productivity is to pick a target that is above what is achievable causing people to work as fast as possible. There is some truth to the argument that people can procrastinate until they have well-defined targets. The idea breaks down when people realize or come to believe that the targets are unreasonable or made without an understanding of the details that went into the estimate. Agile takes a different approach that delivers continuous incremental value. Work is done until the backlog is complete or the ROI is less than the cost being invested. Video Images Used Speaker notes at some future date References https://hbr.org/2017/01/managing-a-team-thats-been-aske

Data Exfiltration Risks - E-mailing Reports

Image
Users potentially leak data every time they send information as part of an email or some other message transport.  Data access controls are rendered useless by data sent as email or other attachments.  Potentially sensitive data is impossible to control or remediate once it is outside the reporting system. Reports with incorrect data live on forever as attachments or saved to local file systems.  The data can never be fixed globally  because no one knows where all the copies are.  This creates data consistency issues and potential regulatory issues We heard this     The new system makes it hard to mail data to my external partners. And our answer was      Yes, it is and you should never have been doing that. Recommendations Admit you have a data problem. Create a policy and train people to stop sending sensitive data as attachments. Recognize that transmitting data without controls is a data Exfiltration

< rant > When your audience recognizes markup in your speech patterns < /rant >

It is probably weird  There are times when I'll put markup like comments in my speech in video conferences.

Create a grammar before defining event models

Image
Software systems stream business events to be seen by customers, used by processes, or written to analytical stores.  Sometimes the best way to initiate a design is to create a grammar, a language, that can be used to generate the data models used in the events. Our first step is to define the  grammar or syntax for  Business Events / Audit Messages in a generalized form. We use this grammar to validate design time event definitions. We can implement that grammar in whatever technology we choose. Business Events are different from technical events. Programs and subsystems generate technical events about invocation and process failure events.  Technical events are targeted at production support, system triage, and data store replication.  Customers and other users expect to see activities in human-readable form. These activities are referred to as  Business Events  or  Business Audits . They define operations one level higher than  Technical Events.