After hours meeting with Wayne, Alan, John, Bryan, and I. Wayne pretty much drove and I took notes. It went for three hours. We have the first two hours recorded (see attached). The last hour, we thought that we were done and it kept going with ideas and more clarification stuff. It may be a lot to read, but I've got 5 pages of notes, all dealing with fracture and where we are heading with adilas lite. Some of these topics are deep, backend, and server and database related. Good meeting.

I have no problem saying this... I was definitely not the smartest person in the room. I've been doing this kind of stuff for over 20+ years and I was impressed. That makes me excited.

Once again, if you want to review the notes, there are a bunch of good things in there for our upcoming fracture or adilas lite project.

These are a few of my takeaways:

- We need to communicate and get some standards setup. This could be what we call things, what code to use and how it looks and acts, and other style guide level stuff.

- Our plan is to build the whole new parts and pieces into an open API socket connection level application. We could then use API sockets as well as let outside developers use the same API sockets. We talked a lot about this. This is where we want to head. The new adilas lite platform will be mostly run on API sockets.

- Rules and assignments - the concept of building the rules and then assigning who plays with those rules was a big part of the discussion. Follow a story-based design for logic, testing, etc. Make all of this data driven.

- Think generic - what is available - what do you want or need? Make everything configurable. Multiple levels of configuration. See notes.

- We will be building a very robust data dictionary and then using that in the rules, validation routines, etc. This is basically a database that shows columns, names, values, rules, defaults, and other information about those columns and/or fields. This is huge and will help us use a more data driven approach vs hardcoding all of the rules, values, and validation per column. We will have a generic set and then let each corp, location, and user tweak a copy, if they want to get that deep. If not, we will use the main master data dictionary list information. Only change and copy what is needed.

- Events and turning everything into small bite sized pieces. Very minimalistic approach. Make as much of this application asynchronous (nonlinear) as possible.

- Let's do the aggregates (data warehousing stuff) right off the bat and get those values in place and being used. We are very good at transactional data and data storage. Let's really make an effort to break into the aggregated or business intelligence (BI) levels. That is a huge goal of ours.