Reflection – Learning Launch 

 Challenge     Greetings . I am part of my company ’s technology architecture department . The challenge is   to make the technology solutioning process more comprehensive , easy to understand for the   developers and at the same taking less time than what it is taking now . The impacted teams   include architects , developers and the business stakeholders . This initiative is limited to only   the internal employees . This ask is to complete this exercise within 12 weeks and should cover   the remodelling of end to end solutioning process , including the way requirements are   consumed and interpreted , artefacts are written and finally the reviews are done to ensure   quality .     Selection     Although there are various aspects of this initiative , I will walk thru the solutioning   documentation part of it . The team had multiple sessions with the stakeholders , in this case   architects , developers and the product owners and came up with a way to create / document   the solution after going thru various pain areas and also potential way to document it . The   learning launch is to experiment with the shortlisted documentation process and access the   insights thereafter .     Application     This learning launch is split into two parts . First , the understanding and writing the   requirement , second , is about the technology design and documentation .   For the first part , we focused on the requirements part . We started with splitting the epics   into smaller user stories and started converting them into technology terms , that is how they   boil down to various different system flows and interfaces between them . The user   experience part of it and the non - functional requirements which will be useful while the   technology design . All this was to make sure that the business requirements were properly   understood and there were no gaps to be found later .   The second part was to take the inputs from the first part and create the technology design   around it , keeping the mentioned systems in mind and also the non - functional requirements   such as performance , resiliency etc .   Additionally , the solutioning were peer reviewed end to end ( both the parts ) , to make sure   the solutioning is seamless flowing from one part to another .     Insight     After applying this process , the team identified the assumptions and this launch tested those   assumptions . Creating a overarching way to document made the solutioning easier as the   designer knew what kind of things to look for in a requirement and the business knew upfront   what they needs to keep in mind which planning for their projects . Another thing we noticed   that , actually the two parts can be done by different set of architects as the skill required to   do both are a bit different . That , is another area where we can do further experiment . The 

 team also looked at other insights as well . This exercise was quite useful before the actual   launch of the process .     Approach     This was a very useful thing to do as we went through the first few design thinking tasks . As I   mentioned above , the team has reviewed the insights from this first launch and plan to   incorporate these insights into future launches , broadly as a tool as well . And we already have   one experiment to do which came out as an insight . Riding on this process , we believe we can   further reflect on the insights , and refine the solutioning experience more to make it even   better . Thank you . 


EMAIL: 
ID_NUM: 
NAME_STUDENT: 
PHONE_NUM: 
STREET_ADDRESS: 
URL_PERSONAL: 
USERNAME: 

### Task: You are a PII (Personal Identity Information) Detection. Given a essays written by students, you have to identify ONLY the following:
NAME_STUDENT - The full or partial name of a student that is not necessarily the author of the essay. This excludes instructors, authors, and other person names.
EMAIL - A student’s email address.
USERNAME - A student's username on any platform.
ID_NUM - A number or sequence of characters that could be used to identify a student, such as a student ID or a social security number.
PHONE_NUM - A phone number associated with a student.
URL_PERSONAL - A URL that might be used to identify a student.
STREET_ADDRESS - A full or partial street address that is associated with the student, such as their home address.
### Input: Reflection – Learning Launch 

 Challenge     Greetings . I am part of my company ’s technology architecture department . The challenge is   to make the technology solutioning process more comprehensive , easy to understand for the   developers and at the same taking less time than what it is taking now . The impacted teams   include architects , developers and the business stakeholders . This initiative is limited to only   the internal employees . This ask is to complete this exercise within 12 weeks and should cover   the remodelling of end to end solutioning process , including the way requirements are   consumed and interpreted , artefacts are written and finally the reviews are done to ensure   quality .     Selection     Although there are various aspects of this initiative , I will walk thru the solutioning   documentation part of it . The team had multiple sessions with the stakeholders , in this case   architects , developers and the product owners and came up with a way to create / document   the solution after going thru various pain areas and also potential way to document it . The   learning launch is to experiment with the shortlisted documentation process and access the   insights thereafter .     Application     This learning launch is split into two parts . First , the understanding and writing the   requirement , second , is about the technology design and documentation .   For the first part , we focused on the requirements part . We started with splitting the epics   into smaller user stories and started converting them into technology terms , that is how they   boil down to various different system flows and interfaces between them . The user   experience part of it and the non - functional requirements which will be useful while the   technology design . All this was to make sure that the business requirements were properly   understood and there were no gaps to be found later .   The second part was to take the inputs from the first part and create the technology design   around it , keeping the mentioned systems in mind and also the non - functional requirements   such as performance , resiliency etc .   Additionally , the solutioning were peer reviewed end to end ( both the parts ) , to make sure   the solutioning is seamless flowing from one part to another .     Insight     After applying this process , the team identified the assumptions and this launch tested those   assumptions . Creating a overarching way to document made the solutioning easier as the   designer knew what kind of things to look for in a requirement and the business knew upfront   what they needs to keep in mind which planning for their projects . Another thing we noticed   that , actually the two parts can be done by different set of architects as the skill required to   do both are a bit different . That , is another area where we can do further experiment . The 

 team also looked at other insights as well . This exercise was quite useful before the actual   launch of the process .     Approach     This was a very useful thing to do as we went through the first few design thinking tasks . As I   mentioned above , the team has reviewed the insights from this first launch and plan to   incorporate these insights into future launches , broadly as a tool as well . And we already have   one experiment to do which came out as an insight . Riding on this process , we believe we can   further reflect on the insights , and refine the solutioning experience more to make it even   better . Thank you .
### Output: 