1 masschallenge technology review masschallenge technology review (april 2011 - july 2011)...

1

MassChallenge Technology Review MassChallenge Technology Review (April 2011 - July 2011)

MassChallenge

Web Technology ReviewApril 2011 - July 2011

Johnny Negretti

Technical Consultant

July 2011

2


Opening SummaryHere are the top issues related to the masschallenge.org website.

1. Flawed Database DesignMajority of the MC website issues are related to Drupal (the current platform) not being able to process correctly the indexes and keyed data, form data, and configurations of loaded nodes/views/blocks/pages/panels/modules/themes.

2. Limited To No DocumentationIt’s near impossible to plan without a documented vision of the current.

3. Current Platform Configuration Is Not ScalableDrupal was not designed to be used to have every component of a website, webpage, and asset be a configured piece.

4. Limited Analytics of Web Activity and Data Processing

3


Drupal Architecture Review

Too many admin call in “dashboard”

Front-end template had ill-formatted HTML and CSS which causes majority of the page load response (main reason for slow website)

Too many modules/views/blocks/etc (estimates) Views: 70% are not needed, 50% are main cause of a slow website

80% should be a “web service” 70% should be hand-coded vs. a ”view”

Modules: 60% are not needed, 40% have conflicts 90% custom “MC” modules cannot migrate and require continual updates

Blocks: 75% are not needed (many are redundant)

Modules are installed without QA of conflicts which have gone unchecked

4


Development Process: Major Issues

1. Bad Data DesignAdding module, new features, creating views, etc without having a clear direction on how the data of the primary nodes and user extended data will cause major platform conflicts and intense page load times. Drupal heavily replies on the design of the data that it stores.

Have a “feature” database design / flowchart.

2. Release Management No changelog

Require ALL website changes be logged.

No updates schedule/cycle Have major website updates occur once a week on a specific day/time and minor updates occur once a day at a

specific time twice a day (excluding major bug fixes).

3. Limited Technical Oversight

5


Development Process: Minor Issues

No “production” website mirroring Haphazard development Too many quick fixes Limited technical management on new development Poor development standards (as in how code is written) Limited quality assurance Silo development on difference areas of the website Sloppy front-end (HTML/CSS) development (major cause of a slow website) Executives have too much on their plate to take full ownership of process Password don’t change Limited to no documentation on technical environment No “DBA” (database administrator) Too many 3rd party assets are stored locally and not within a “cloud” No real “sandbox” environment

6


Website Project Management

Bug list is not prioritized (No “Priority” list)

No “ownership” of the website

Limited to no documentation on what the website “features” are

Limited insight into operational budget of the website

Design and User Experience (UIX) is managed by too many resources

Unknown risks

Homepage is unmanaged (and stale)

Static content does not expire

No search????

7


Closing SummaryHere are the top areas that need to addressed.

1. Clean The Data!!!If the data (DB content specific to MC) is not normalized and properly adjusted then any further work on the MC website will continue to not be able to scale.

2. Separate Websites (regardless of platform)Many of the current “issues” with the MC website are related to the Drupal admin (dashboard) and have been having major effects on the static website. These two should be separate.

3. Use “Web Services” vs. Configured Content (regardless of platform)Using web services to create page content and design logic will drastically help with the scalability and speed of the website. This is the industry standard of today.

4. Release ManagementRegardless of what platform/technology is used, not being able to track what is changed will drastically delay updates and cause many development conflicts.

8


Next Steps Schedule

July (early): Close out 3 months (April 2011 - July 2011) July: “On-Call” assistance July (mid) - August (late):

Volunteer technical assistance/production development July (late) - August (mid):

Volunteer development to “Migration” (data cleanup) Week 1: Clean/Migrate Data (Johnny) Week 2: Clean/Migrate Data (Johnny/MassChallenge)

Next step depended on platform direction Week 3: Migrate Modules/Views (MassChallenge/Johnny) Week 4: Migrate Modules/Views (MassChallenge)

1 masschallenge technology review masschallenge technology review (april 2011 - july 2011)...

Documents