Platform Service Transformation: Entry 2 – Platform Architecture and ReDesign: Phase One

ArchitecturalView  

Platform Architecture and ReDesign: Phase One


2nd Entry

The purpose of this project is to unbind and unfetter a great service and product from debilitating, confusing and circuitous code. As in many cases, the code for products, is a result of many years of different code practices, developers, loss of methods in favor of “quck-fixes” to support Production. The result is a hairy, overgrown, complex, and code with nothing but dead ends in its future (in other words, non-scalable, with too many hard coded restrictions)

The Challenge is to re-design and construct a new infrastructure that IS scalable, flexible and elegant, without the User Experience changing. It may be improved, but for a more intuitive work flow’s sake, retaining the functionality on which the customer base is dependent.

The Tool Stack being used in current project for code re-factoring and re-design:
In order to transform a platform riddled with inefficient code, and work flow paths, we are consolidating DB Calls and Posts, using the following to create new service based middleware (to replace the PHP assignments): Cloud based iterations for DEV, DEVOPS, R&D, Ruby, Java, RAML for new APIs, ElastiSearch, Kibana, Jenkins, Cucumber, PHP (unraveling and re-assigning), Version One, Apache, Oracle, customized code generation, common sense, and Top-Down development and sensible deliveries for each sprint. Each of the teams (2 – Dev, UI/Biz) own their parts, and there are also intersects between the team functions for each team member. Some more than others.

CloudArchitectureMap
Example: NOT Actual

While we have spent a good bit of time re-engineering the product, we have realized, that we are limited in our demos to reflect the present level of functionality based upon the existing product. In order to fully service the needed functionality at the needed scale, we will begin development from the Top Down, rather than the discovery based Bottom Up approach. The Bottom Up approach has been useful in revealing many of the flaws, design complexities and inefficiencies, and workflows. This realization also provides the reality of NOT developing certain functional sections such as Security – already complex, into a flawed model. Once the present demo is completed to demo for execs, the functionality based upon the Bottom Up approach will be retained, but developed from the Top Down.

This shift in approach will allow implementation of complex features from a fresh start, designed to scale, and efficient.

Next Entry coming soon!

Advertisements

Vendor Management Service Transformation: Entry 1 – Re-Factoring, Businss Architecture

metodo_pratiche_agile_chart_manifesto_itaEntry 1    3.22.2015

I recently was invited to join a project for a Vendor Management Service (VMS) in Mid-March 2015. The project is to provide in Phase 1 a re-factoring of our Client’s code by replacing the hardcoded middleware with services, and adding new client facing features, along with a new UI. All needing new documentation, of which there is now verylittle.

Our client provides a turnkey service for managing IT vendors who need to outsource their HR, Recruiting, Accounting, and Financial Services for this aspect of their business.

My role is to document the present legacy Business Processes, the new Processes, the new Services and the newly re-factored APIs, processes and added features by providing the Requirements, Use Cases, Workflows and Processes.

The leadership on this project is not only setting the pace, but shining a bright light into the future vision for this client, and for the VMS industry. It is a privilege to work with them.

 

Presently, I am awash in the project ramp-up and assimilation of the many layers, features and infrastructure required to successfully launch a program as complex as this.

We have two teams: one is onsite with FTE EEs of the customer, and a fly-in contingent of our leadership. The other is an offsite team in Atlanta, that is providing an AGILE based component for delivery of the new code which provides the new Service APIs and integration; as well as Leadership, Business Architecure, Process Articulation & Documentation. The client will observe the present SDLC based approach for now.

We have defined the primary users and their roles, the features – both new and old – associated with their roles. The functionality of these features some of which, for now, will remain as legacy, while others are new. There are around 400 of these. Some are Epic, requiring some of the features to support the workflows.

For the new and replacement pieces (in AGILE) we have defined the primary “Day in the Life” from the “need to the ass in the seat” E2E process to establish a critical Happy Path. Variations and UCM will be modeled based upon this primary structure.

The software and coding will be the same, albeit updated. The specific usage of the system will vary based upon the needs and systems of client-users of this system.

The SDLC pieces for things like the DATA, and QA will be driven from the client sites.

I will be updating this log at various points along the way…. so STAY TUNED!!

Bill Fulbright

Security in 2015 – What measures will be implemented to improve it?

by ,  Sr. Quality Strategy and Delivery Advisor

Is Security in your environment covered?

  • Do you have a full rundown/analysis of the gaps you may have in your system?
  • Have you created a checklist of all:

    • touchpoints
    • protocols
    • profiles
    • methods of transmission
    • firewalls
    • frequency of sweeps
    • frequency of security monitoring status reports?
    • Do you have a network ops monitoring application?

imageThis is not the year to be avoiding the security risks afoot … not only from your own employees, random local hacker, but serious international hacking as pro-active attacks on your system. 2014 demonstrated an increase in security leaks – or might i say exposure of weak security by upstream hackers with malicious intent. Expect more of it. Breaches have been happening every year for some time. We are no longer surprised by them. It is another overload of input that we as consumers can do little to prevent.

Prevention of security leaks are up to those responsible for maintaining our private accounts and data. That they have allowed weaknesses that are gaps, and hackable, is irresponsible, unacceptable, and once leaked causes much damage financially, and personally.

What is a Threat Agent?

The term Threat Agent is used to indicate an individual or group that can manifest a threat. It is fundamental to identify who would want to exploit the assets of a company, and how they might use them against the company.  You can read more about it here:
https://www.owasp.org/index.php/Category:Threat_Agent

Here are some Highlights from Open Web Application Security Project “Attacks” references:
https://www.owasp.org/index.php/Category:Attack

Looking forward to seeing deeper security measures, and fewer assailable gaps by our financial institutions and retailers.

All comments invited.

Lack of Integrity and Moral Grounding causes breach in security for Morgan-Stanley and others

PCWorldNews-LOGO Morgan Stanley fires employee who leaked sensitive client data

By now, this is old news. by 2 days. And this is not the first or the last time…

BUT, the issue is: how to contain actions of rogue employees, who for one reason or another choose to leak data to create either fraud, embezzlement, or just outright malicious damage.

-or-

Change the hiring and training of those with deep security access.

Here is another case of actions taken by people who lack integrity or the moral certitude (to prevent them from such) that cause the rest of us to suffer either through monetary loss, or tighter security – both are reactionary, after the fact, and hard to recover…

IMG_3144Solutions? Creating higher level, invisible, security barriers around known system security? Improving morale? Creating behavioral awareness that is alert to potential disgruntled behavior? Or creating a higher standard of integrity for those with deep security access? Better background screening?

Return to integrity anyone?

2015 Hospital Hacks, Banking and Retail Hacks, Entertainment Hacks – Attack On Financial Services

This post on my blog QA2100.com is in reference to a great post highlighted by Jaden Turner’s share on 2015 Hospital Hacks: and posted into our Group on Linked In:  QA2100 Testing Strategy: Financial Services

Every week we are hearing about another leak, hack or break-in and millions of credit card holders are exposed, at risk, or invaded.   Who are these hackers?  Why are they hacking?  Money.  Greed. Something for nothing.  Retribution.    All of which is Vicious, Criminal and
destructive to infrastructure, commerce, and consumer confidence

Security – is this an oxymoron? We hear it, and aretaught to believe it, so we truWhyItMattersst that others are responsible about implementing it. Real Security means real testing dollars are spent beyond the boundaries of a new project launch… Usually only the minimal security testing is considered if at all. If it is, is usually not part of projects, rather it is part of the ‘network’ group, or ‘infrastructure’ group.

So, this is not about the kind of job our network guys are up to, rather the kind of budget that gets allocated to supporting enough security measures, plus the budget to ensure it is being implemented and maintained at a deep enough or broad enough level. This means maintenance, and keeping up with the latests shenanigans by our nefarious ‘hackers’.

I have the same issues with performance testing. and automation for regression.

So I could go on, but these areas are allowed to get weak due to higher priority profit making budgets. and on and on until an emergency effort to shore up security is done again. Security = Insurance. If you don’t spend the money on the protection, it won’t be there when you need it.

This is the tip of the IceBerg and we need to be vigilant, and attentive to the looming prospects of risk.