Iron Square of Constraints

If you have spent any time involved in projects and dealing with project managers, I'm sure you have heard of something called the "project management triangle".  If you haven't, here is a quick look.

This diagram is used to outline the constraints a project faces, and how they are related to each other.  It is common wisdom that you can't "control" all 3 of these constraints.  That is to say, if you want to fix the cost and the schedule, then you have to be flexible on the scope of the project.

There are many tools that can be used to measure/understand/control the various constraints above.

Cost

Cost is always an interesting one.  Generally, cost is measured as a function of money that is put in to creating the product.  For example, one would consider the resources being used on a project, the labour rates of those resources, and any additional costs (desks, licensing, etc).  Risks to the cost of a project are generally detailed as part of the risk register and reported up to the project stakeholders.

One thing that is often overlooked is the cost of NOT doing something.  For example, ROI on a particular workload may only be realized if the product is first to market.  Thus, a schedule that slips may have a significant cost implication above and beyond the cost of the resources on the project. 

Scope

Scope is generally defined as the requirements specified to achieve the end result.  If you are doing a good job of this, you are capturing both the functional AND non-functional requirements. 

Schedule

This constraint is generally expressed as a "go-live" date or "target" date.  While it is understood that this should not be a completely arbitrary date, most end up being this way anyways.  In theory, this date should take into account cost/scope considerations. 

Quality

It is important to note that the concept of quality is muddled in the diagram above. Looking at it, you see that quality seems to be this thing that is made up of the combination of cost/scope/schedule.  It isn't quite understood that quality can be a target on it's own.

In the book, Management 3.0, the author describes his view on the "Iron Square of Constraints".

Talking about the constraints above as a gradient is truly a powerful tool.  Let me give an example.  It can be extremely difficult to build a application that is highly scalable.  It takes a lot of work to do this, and can add significant time to the project to build out completely.  For a proof of concept, or a limited release, project stakeholders may decide to forgo some of the quality aspects in favour for more functionality, or, less time/resources.

It also is a better visual to show trade-offs.  Given constrained resources and time, I have a choice to deliver many features with low quality, or fewer features with high quality.

This holds true for a mythical customer that wants to hold quality and time as constraints.

They would have the option of changing the resources assigned to the project, or fiddling with the amount of functionality that is delivered.

Later on in the book, the author discusses the "Escher cube of constraints".  It looks something like this.

While I think it is ultimately a more complete version of the constraints in play, this might be a little much to discuss with a customer during initial project discussions.

Considerations for your next centralized Identity Provider

It is no secret that cloud adoption is hitting new record rates.  The number of SaaS applications has exploded and the value they provide is so tempting that many businesses are jumping on board.  Unfortunately, this has caused some severe headaches for IT departments.  One such headache is how to manage authentication and authorization concerns on those SaaS applications in a scale-able way.

When choosing a centralized identity provider, there are a few considerations I like to look at.  More specifically, there are a few key capabilities that I like to assess as part of my decision making process.  It is important to note that a holistic identity management solution requires both the identity provider and the target application to support certain capabilities.

Consideration 1: Single Sign-on

A centralized idp wouldn't be much if it couldn't facilitate single sign-on capabilities.  What I would generally look for here is something that is capable of all the latest standards (read SAML 2.0).  Further, I am looking for some type of password vaulting technology that allows me to share passwords between multiple team members without actually giving them the password.  This is an important use case for scenarios such as corporate facebook or twitter accounts.

Consideration 2: Authorization

Not only am I looking for authentication capabilities, I also want to be able to authorize my users from a single place.  While heavily dependent on the target application, I want my idp to be able to set custom claims to help govern access to target applications from a centralized spot.  This reduces the load on IT and business super users for maintaining and managing access.  It also allows for one centralized spot for auditing of access across the enterprise.

Consideration 3: Provisioning

A lot of headway has been made in the automatic provisioning space.  In an ideal world, however, all applications would comply with the SCIM standard for cross-domain identity management.  This would make it really easy to CRUD users into those systems from a central source.  For this capability, I'd expect my idp to be flexible.  Ideally there are built-in integration with providers, but also an opportunity to add in custom integration to API endpoints to facilitate the provisioning process.  

Consideration 4: Attribute Exchange

There is generally more to configuring a target SaaS application than user data exchange.  In a lot of cases, the provisioning and authorization process will provide access to a subset of company data based on something like store locations, or departments, or some sort of hierarchy relationship.  Ideally, I can pass that information as part of some sort of attribute exchange during the provisioning of that SaaS application.  Further, I'd hope that my idp can do this for me, providing once again, a single point of management.

This capability is a little bit more pie-in-the-sky and I haven't seen too many idps meet this need.

Consideration 5: Audit and Compliance

Lastly, an idp should have really strong audit, compliance, and security components.  For example, the idp could integrate threat intelligence to help determine potentially compromised credentials.  Reporting should be able to answer compliance questions as required (who has access to what), and each login should be audited and tracked.

In short, there are a few key considerations when looking at centralized idp mechanisms.  The big names out there are making large strides in this area.  One area that needs consumer help is putting pressure on the 3rd party applications to comply with the latest industry standards such as SCIM and SAML.

MS 70-534: Architecting Microsoft Azure Solutions - Certified

Continuing with the writing of MS exams, I just passed 70-534.  I found this exam easier than the 532 exam.  While it does focus on a broad range of subjects, there seems to be little focus on some of the newer technologies such as service fabric, or other ones such as security center, etc.  I understand that some of those technologies are still in preview, but it is shocking how out of date some of these exams can be.

Good luck if you plan on writing it.